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VORWORT 

Die Programmiersprache Modula-2 wurde Ende der 70er Jahre als direkte Nachfolgerin der 
Sprachen Pascal (1970) und Modula (1975) an der Eidgenössischen Technischen Hochschule 
Zürich unter der Leitung von Professor Niklaus Wirth entworfen. Die Zielsetzung eines im 
Jahre 1977 begonnenen Forschungsprojektes war es, ein Rechnersystem (Hard- und Soft¬ 
ware) in einem einheitlichen Ansatz zu entwickeln. Die Sprache sollte daher sowohl der 
Systementwicklung auf hoher Ebene, als auch den Anforderungen auf niedriger, maschi¬ 
nennaher Ebene gerecht werden. Die erste Implementierung wurde 1979 fertiggestellt, 1980 
erfolgte die Veröffentlichung der Sprache Modula-2. 

Modula-2 ist Pascal recht ähnlich, was dem Pascal-Programmierer den Umstieg erleichtern 
dürfte. Die Erweiterungen und Verbesserungen gegenüber Pascal sind aber gravierend. Sie 
lassen sich in vier Punkten zusammenfassen: 

• Modulkonzept 

• maschinennahe bzw. systemnahe Elemente 

• Prozedurtyp 

• syntaktische Straffungen 

Pascal hatte einige Nachteile bei der systemnahen Programmierung, zum Beispiel waren keine 
direkten Speicherzugriffe möglich. Bei der Entwicklung großer Programme bereitete es 
Schwierigkeiten, daß man diese nicht in kleinere, übersichtliche Einheiten zum getrennten 
Übersetzen und Austesten zerlegen konnte. Außerdem fehlte die Möglichkeit, bereits vor¬ 
handene Funktionen aus »Bibliotheken« einzubinden (beides war in FORTRAN schon 
üblich, ähnlich wie in C). Da dies aber oft unumgänglich ist, bieten verschiedene Hersteller 
eigene Pascal-Dialekte an, die mit dem Standard-Pascal oft wenig gemeinsam haben. 

Pascal konnte sich auf dem Atari-ST nicht so recht durchsetzen. Dahingegen gibt es seit kur¬ 
zem mehrere Modula-2-Compiler, die zum Teil direkt von dem von Wirth konzipierten adap¬ 
tiert worden sind. Mit Modula-2 ist dem Atari-ST-Benutzer eine Sprache mit sehr hohem 
Niveau gegeben, mit der er dennoch systemnah programmieren kann. Es ist daher nicht ver¬ 
wunderlich, daß das Interesse an Modula-2 sprunghaft angestiegen ist. Die Vormachtstellung 
von Pascal im Lehrbereich sowie die von »C« im Bereich der Systemprogrammierung wird 
angegriffen, was nur verständlich ist, da Modula-2 die Stärken beider Sprachen vereint. 

Modula-2 wurde speziell zur Entwicklung großer Programmprojekte entworfen. Es unter¬ 
stützt die Möglichkeit der schrittweisen, strukturierten Programmerstellung in separaten 
Einheiten, den sogenannten »Modulen«, die getrennt übersetzt, geprüft und anschließend zu 
einem Programm zusammengefügt (»gelinkt«) werden. Die Aufrufe der System-Routinen 
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sind einfach über die mitgelieferten Module möglich, wodurch eine Programmierung unter 
GEM leicht realisiert wird. Der Benutzer hat mit den zum Teil integrierten Debuggern und 
Assemblern brauchbare Entwicklungspakete zur Verfügung, die keinen Vergleich zu scheuen 
brauchen. 

Das vorliegende Buch über Modula-2 berücksichtigt sowohl den Leser, der sich in diese 
Sprache einarbeiten will und nur wenige oder keine Programmierkenntnisse besitzt, geht aber 
in starkem Maße auch auf den erfahrenen Programmierer ein, der mit den Sprachen Basic, C, 
Pascal oder Modula-2 vertraut ist. 

Ziel ist es, jeweils mit grundlegenden Programmiertechniken beginnend, den Leser schnell an 
professionelle Module für den jeweiligen Themenkreis heranzuführen, so daß in jedem Fall 
fortgeschrittene, optimierte Routinen geboten werden. Das Konzept ist also, den Leser 
schnell von »Null« auf »High-Level«-Programmierung zu bringen. 

Der Stil der Beschreibung ist dabei knapp gehalten, aber ausreichend informativ und enthält 
konkrete Hinweise auf die Programmierfeinheiten (z.B. Geschwindigkeitsoptimierung). Ins¬ 
gesamt erhält der Leser neben einer nach didaktischen Prinzipien erstellten Einführung eine 
Fülle von allgemein nützlichen Routinen und Modulen, die auch der professionelle 
Modula-2-Programmierer für die Einbindung in eigene Programme zu schätzen wissen wird. 
Die Programmentwicklung wird durch die Prozedurenbibliothek, die dieses Buch bietet, be¬ 
quemer und zeitsparender. 

Die Grobgliederung des Buches ist folgende: 

Kapitel 1: Spracheinführung 

Kapitel 2: Behandlung wichtiger Datenstrukturen 

Kapitel 3: Benutzung des 68000-Assemblers unter Modula-2 

Kapitel 4: GEM-Programmierung unter Modula-2 

Kapitel 5: Demonstration der Entwicklung eines komplexen Programmprojekts 

Die ersten beiden und das letzte Kapitel sind für jeden Modula-2-Programmierer von Inter¬ 
esse, unabhängig davon, mit welchem Rechner er arbeitet. Kapitel 3 spezialisiert sich auf 
Computer mit dem 68000-Prozessor. Das 4. Kapitel enthält hauptsächlich Atari-spezifische 
Eigenheiten. Im einzelnen: 

Zu Kapitel 1 

Nach einführenden Beispielen werden die vielfältigen Datenstrukturen von Modula-2 be¬ 
sprochen. Hierbei ist es didaktisches Prinzip, zu erläutern, wie die Daten im Speicher abgelegt 
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werden. Dies erleichtert das Verständnis der Datenstrukturen und ist besonders bei der Be¬ 
handlung von Zeigern vorteilhaft. 

Der eilige und erfahrene Pascal-Programmierer wird diese beiden Abschnitte und die folgen¬ 
den drei über Standard-Prozeduren, Kontrollstrukturen sowie das Prozeduren-Konzept 
sicherlich rasch lesen können. Auch kann er sich zunächst einen Überblick über die Unter¬ 
schiede von Pascal und Modula-2 verschaffen. Neu dürfte für ihn jedoch das Modul-Konzept 
und die Bearbeitung paralleler Prozesse sein. Für den Anfänger ist das intensive Durcharbei¬ 
ten des gesamten Kapitels 1 ein Muß! 

Zu Kapitel 2 

Hier werden komplexere Datenstrukturen wie Felder, Verbünde, dynamische Datenstruktu¬ 
ren und Dateien behandelt. 

Die einzelnen Abschnitte sind dabei so aufgebaut, daß sie dem Neuling in leicht verständlicher 
Form eine Einführung geben, die dann aber rasch mit Programmierfeinheiten gewürzt wird 
und dann ohne Umschweife zu Prozeduren führt, die auch dem Profi nützliches Handwerks¬ 
zeug für seine Programme bieten. 

Bei der Behandlung der verzeigerten Strukturen wird großer Wert darauf gelegt, dem Leser die 
Darstellung der Daten auf dem »Heap« im Speicher vor Augen zu führen. Die üblichen Pro¬ 
grammierfehler, die bei Zeigern oft auftreten, dürften sich so weitgehend vermeiden lassen. 

Zu Kapitel 3 

Dieses kurze Kapitel zeigt die Benutzung des 68000-Assemblers von Modula-2 aus, die sich 
dann anbietet, wenn es um die Optimierung geschwindigkeitskritischer Routinen geht. 

Für den in 68000-Assembler unerfahrenen Leser wird im ersten Abschnitt die Einführung in 
die Befehlsklassen des Prozessors gegeben. Dieser Teil wird durch eine Tabelle im Anhang 
zum Nachschlagen abgerundet. Die Assemblerkenntnisse werden zur Erstellung eigener Mo- 
dule genützt (Spracherweiterung). 

Zu Kapitel 4 

Im 1. Abschnitt geht es darum, den Atari-Neuling mit den Betriebssystem-Routinen und dem 
GEM vertraut zu machen. Dem auf dem Atari erfahrenen C-, Pascal- oder Assembler-Pro¬ 
grammierer nützen hier die Ausführungen über die verschiedenen Module. Es wird also das 
Dickicht der zahlreichen Routinen geordnet nach dem Prinzip »Was benötige ich für welchen 
Zweck?«. 

Im folgenden werden Anwendungen zur Fenstertechnik, Menütechnik und Grafik gezeigt. 
Der Abschnitt über Grafik wird neben einem vielseitig nutzbaren Modul mit Grafikprozedu- 
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ren durch einige interessante Programme über Mandelbrot-, Juliamengen sowie Simulations¬ 
programmen - unter anderem zu Satellitenbahnen - abgerundet. 

Es geht hier also nicht um die in der Literatur zum Atari weitverbreitete Aufzählung der 
Systemroutinen, sondern es soll in exemplarischen Anwendungssituationen gezeigt werden, 
wie man sie einsetzt. 

Zu Kapitel 5 

Das Abschlußkapitel zeigt ein größeres Programmprojekt auf. Es geht um ein ausgefeiltes 
Funktionenplotprogramm. Auch hierbei werden in einzelnen Teilabschnitten theoretisch an¬ 
spruchsvolle Sachverhalte schrittweise klargemacht. 

Im einzelnen geht es um das »Scannen« und »Parsen« von Termen als Zeichenketten (grenzt 
etwa an Compilerbau), die Bildung der Ableitung einer Funktion als Zeichenkette, Optimie¬ 
rung der Integration sowie grafische Darstellung von Funktionen. Hier werden Methoden der 
Kl-Programmierung (künstliche Intelligenz) genutzt. Das fertige Programm zeigt bei¬ 
spielhaft, wie man unter GEM eine sinnvolle Benutzerführung programmiert (Menütechnik, 
Maskeneingabe, Ausgabe in Fenstern u. ä.). Außerdem geht es um die Anwendung der in den 
vorangegangenen Kapiteln vorgestellten Hilfsmodule, so daß insgesamt interessantes An¬ 
schauungsmaterial für die Behandlung eines größeren Programmpaketes unter Modula-2 
demonstriert wird. 

Die Quelltexte sämtlicher Programme dieses Buches befinden sich auf den beiliegenden Dis¬ 
ketten. Die 150 Files sind in 5 Ordnern kapitelweise gegliedert. Auf beiden Disketten finden 
Sie »LIES-MICH-Dateien«, die über den Inhalt und die Handhabung Aufschluß geben. 

Abschließend möchten wir Herrn Hans Helmut Hager und Herrn Alfred Rodenbücher für die 
Durchsicht unseres Manuskripts, sowie Carmen für die Geduld, die sie uns während der Ar¬ 
beit an diesem Buch entgegengebracht hat, danken. 

Wir wünschen dem Leser viel Freude bei der Lektüre dieses Buches sowie bei der Erstellung 
eigener Modula-Programme! 

Jochem Schnur 
Stefan Dürholt 
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Die ersten Schritte 


1.1 Die ersten Schritte 

1.1.1 Installierung des Modula-Entwicklungspakets 

Das gesamte erste Kapitel sollten Sie gründlich durcharbeiten, bevor Sie ihr erstes Modula-2- 
Programm schreiben. Da Sie diesen Rat sowieso nicht befolgen, beginnen wir gleich mit drei 
einfachen Programmbeispielen. 

Zuvor müssen Sie jedoch das Modula-Entwicklungspaket installieren. 

Wir haben bei der Arbeit an diesem Buch folgende Systeme verwendet: 

1. Hänisch-Modula-2 der Firma Rolf Hänisch Software, Berlin 

2. Megamax Modula-2 der Firma Application Systems Heidelberg 

3. MSM2 der Firma Modular Software, Firnau und Krey, Kronshagen 

4. SPC-Modulci-2 der Firma advanced applications Viczena, Karlsruhe 

5. TDI-Modula-2/ST der Firma Modula-2 Software Ltd., GB-Bristol 


Desk Datei Editor Block 



Bild 1.1: Hänisch-Modula-2 























Installierung des Modula-Entwicklungspakets 


17 



MEGAMAX Modula-2 Shell 


Version 1.1 


(C) 1987 Thonas Tenpelnann 
Manuel Chakravarty 
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Bild 1.2: Megamax Modula-2 
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Bild 1.3: MSM2 
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Bild 1.4: SPC-Modula-2 
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Bild 1.5: TDI-Modula-2/ST 
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Alle Modula-2-Systeme für den Atari arbeiten mit einem komfortablen Rahmenprogramm, 
einer sogenannten »Shell«. Dieses Programm wird vom »Desktop« (so nennt sich die Arbeits¬ 
fläche, die Sie auf dem Bildschirm sehen, wenn Sie den Atari einschalten) aus gestartet, und Sie 
können nun von hier aus den Editor, Compiler und Linker mit der Maus anwählen. 

Der Editor dient dazu, Programmtexte einzutippen und abzuspeichern. Verschiedene Funk¬ 
tionen des Editors helfen bei der Arbeit, beispielsweise beim Verschieben von Textblöcken 
oder beim Suchen von Wörtern. Die meisten Funktionen lassen sich über die Menüleiste mit 
der Maus anwählen. Schauen Sie sich die verschiedenen Punkte an; ihre Kenntnis ist für ein 
effektives Arbeiten wichtig. 

Der Compiler hat die Aufgabe, aus dem Programmtext nun Code zu erzeugen, der auf dem 
Atari ablauffähig ist. Nach fehlerfreier Übersetzung - das heißt, wenn der Programmtext in 
Ordnung war- können Sie Ihr Programm sofort von der Shell aus laufen lassen und austesten. 

Direkt vorn Desktop (ohne die Shell) ist das Programm so nicht zu starten, da es Funktionen 
benötigt, die ihm vom »Laufzeit-System«, wozu auch die Shell gehört, geliefert werden müs¬ 
sen. Werden dem Programm aber die Funktionen direkt eingebaut, so kann es auch ohne die 
Shell auskommen. Dieses Zusammenbauen übernimmt der Linker (= Binder). 

Neben dem Dreiergespann Editor - Compiler - Linker gibt es noch andere nützliche Einrich¬ 
tungen in der Shell, die Sie bei der Entwicklungsarbeit unterstützen können. So haben Sie in¬ 
nerhalb der Shell die Möglichkeit, mit Dateien umzugehen, ähnlich wie Sie es vom Desktop 
her gewohnt sind. Man kann sich innerhalb der Shell das Inhaltsverzeichnis von Disketten an- 
sehen und Dateien löschen oder kopieren. Normalerweise werden Sie aber den Editor oder 
Compiler auf die Dateien loslassen, so daß Sie während der Entwicklung von Programmen die 
Shell kaum verlassen müssen. 

Um optimal mit der Modula-Shell arbeiten zu können, ist eine einmalige Voreinstellung des 
gesamten Systems nötig. Diese Voreinstellung ist abhängig von der Hardwarekonfiguration 
Ihres Arbeitsplatzes. Hierbei spielt die Größe des Speichers und das Vorhandensein einer 
Festplatte eine Rolle. 

Da Diskettenzugriffe auf dem Atari relativ lange dauern, ist es sinnvoll, bestimmte Teile des 
Systems permanent im Speicher zifhalten. Dies kann auf einer RAM-Disk geschehen. Damit 
zu Beginn einer Arbeitssitzung stets die gleichen Teile permanent geladen sind, gibt es die 
Möglichkeit, diese Voreinstellungen in einer Informationsdatei festzuhalten. Bei einem 
neuerlichen Start der Shell wird diese Informationsdatei gelesen und die Arbeitsumgebung 
entsprechend konfiguriert. In dieser Datei werden auch die Suchpfade für Ihre edierten Texte 
und die übersetzten Module festgehalten. 

Bitte haben Sie Verständnis dafür, daß wir hier nicht die Installationsprozedur im einzelnen 
vorstellen können. Sie ist, wie gesagt, von Ihrer Hardware und vom jeweiligen Modula-System 
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abhängig. Das Handbuch zu Ihrem System gibt Hinweise für die Voreinstellungen, mit denen 
Sie effektiv arbeiten können. Eine sehr benutzerfreundliche Methode zur Installation ist bei 
SPC-Modula gegeben: Hier kann man ein Programm namens INSTALL. PRG starten, das ge¬ 
steuert nach Benutzereingaben, die Installation vornimmt. 


1.1.2 Erste Beispiele 

Sie haben es sicher geschafft, von der Shell aus den Editor zu starten. Tippen Sie nun folgenden 
Text und achten Sie beim Abschreiben unbedingt auf Groß- und Kleinschreibung. Wenn Sie 
allerdings keine Lust haben, den Text selber einzugeben: Er befindet sich auch auf der Diskette 
und hat den File-Namen BEISPIE1. M und kann in den Editor geladen werden. 

MODULE ErstesBeispiel; 

PROM InOut IMPORT WriteString, WriteLn; 

VAR i : CARDINAL; (* zum Zählen *) 

BEGIN 

POR i:=1 TO 100 DO (* läuft für i:=1,2..100 *) 

WriteString(”Hurra, mein erstes Modula-Programm läuft!”); 

WriteLn (* Zeilenvorschub *) 

END 

END ErstesBeispiel. 


Verlassen Sie den Editor und kompilieren Sie den Text. Wenn Sie nicht das Megamax-System 
benutzen, sollten Sie die Datei zuvor in BEISPIEL. MOD umbenennen. Das gilt für alle Modu- 
le dieses Buchs und kann vom Desktop aus mit dem Menüpunkt »zeigelnfo. . . « erledigt 
werden. 

Falls der Compiler Fehler findet, hat man die Möglichkeit, in den Editor zurückzukehren. Der 
Cursor steht auf der Fehlerstelle. Im Anschluß an das erfolgreiche Ausmerzen der Fehler star¬ 
ten Sie das Programm. 

Nach diesem ersten Erfolgserlebnis sollten wir uns den Programmtext einmal genauer an¬ 
schauen. Das erste Wort heißt MODULE, das wie alle »Schlüsselwörter« der Sprache groß ge¬ 
schrieben wird (siehe 1.2.2). MODULE kennzeichnet den Programmanfang (für Pascal-Pro¬ 
grammierer: es ersetzt das Wort PROGRAM). Dahinter folgt ein »Bezeichner«, das ist ein Name, 
den Sie sich in gewissen Grenzen aussuchen dürfen. In einem Bezeichner darf kein Leerzei¬ 
chen stehen. Man macht deshalb von Groß- und Kleinschreibung Gebrauch, um ihn aus meh- 
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reren Wörtern zusammenzusetzen. Die weiteren Spielregeln werden im Abschnitt 1.2.1 erläu¬ 
tert. 

Anschließend folgt eine »Importliste«, in der angegeben wird, von welchen schon existieren¬ 
den Modulen Teile »importiert« werden sollen. Die Sprache Modula-2 - im folgenden auch 
kurz »Modula« genannt - selbst hat selbst keine Funktionen zur Eingabe und Ausgabe. Das 
wird denjenigen verwundern, der Programmiererfahrung in Basic oder Pascal hat. Überwin¬ 
den Sie diesen Kulturschock! Es hat durchaus Vorteile, daß die Ein- und Ausgaberoutinen 
nicht mehr von der Programmiersprache selbst festgelegt sind, sondern aus mitgelieferten ex¬ 
ternen Modulen abgerufen werden können. Module können nämlich ausgetauscht werden, 
auch durch selbstgeschriebene. Diesen Vorteil werden Sie später noch zu schätzen wissen. Ein 
weiteres Plus ist die getrennte Übersetzbarkeit. Module können separat entwickelt, ausgete¬ 
stet und kompiliert werden. Man braucht nicht immer alles mit zu übersetzten, was schon 
längst läuft. Der Code kompilierter Module wird dem neuen Programm einfach »hinzuge¬ 
linkt«. Module sind also flexible Programmbausteine. Haben Sie also keine Angst, gleich zu 
Beginn mit ihnen Bekanntschaft zu machen. Ohne Module läuft in Modula nämlich nichts! 

Kommen wir nach diesen generellen Bemerkungen auf unser Programm zurück. Ein- und 
Ausgabeprozeduren kann man sich einfach holen: es gibt sie unter anderem im Standardmo¬ 
dul inOut, der zu jedem Modula-System mitgeliefert wird. Wir benötigen WriteStringum 
eine Zeichenkette (= »String«) auf dem Bildschirm zu schreiben und WriteLn(»Write Line«) 
für einen Zeilenvorschub, also um eine neue Zeile zu beginnen. 

Als nächstes brauchen wir eine Variable zum Zählen. Ihr Name ist i und ihr »Datentyp« ist 
CARDINAL, was die natürlichen Zahlen 0, 1,... 65535 beinhaltet. Es folgt der eigentliche Pro¬ 
grammtext, welcher zwischen BEGIN und END<Modulname> gefolgt von einem Punkt steht. 
Unser Programm besteht aus einer Wiederholungsanweisung, einer »FOR-Schleife«. Zunächst 
wird die Variable i auf 1 gesetzt und der Schleifenrumpf (das, was hier zwischen dem F0R 
und dem dazugehörenden END steht) ausgeführt. Der Rumpf besteht hier aus einer Textaus¬ 
gabe gefolgt von einem Zeilenvorschub. Anschließend wird i um 1 erhöht - das macht die 
FOR-Schleife automatisch - und das ganze läuft von vorne ab. Zum letztenmal, wenn i gleich 
100 ist. Das erste END markiert das Ende der Schleife, dann folgt die Programmende-Markie¬ 
rung. Wenn Sie Pascal kennen, fällt auf, daß der Schleifenrumpf nicht mit BEGIN und END 
geklammert ist. In Modula braucht man hier kein BEGIN, da FOR in Modula immer ein END 
verlangt. 

Text, der zwischen »(*« und »*)« steht, wird vom Compiler nicht beachtet. Man kann dort 
einen beliebigen Kommentar einfügen. 

Auch im nächstem Programm geht es um die Ausgabe von Zeichenketten, aber außerdem 
noch um Eingaben: 
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MODULE ZweitesBeispiel; 

BROM InOut IMPORT WriteString, WriteLn, ReadString, Read; 

VAR antwort : CHAR; (* ein Zeichen *) 

name : ARRAY [0..79] OP CHAR; (* Zeichenkette mit 80 Zeichen *) 


BEGIN 

WriteString("Geben Sie bitte Ihren Namen ein : ”); 
ReadString(name); 


REPEAT 

WriteLn; WriteLn; 


(* Wiederhole das Folgende... *) 

WriteString("Halle 

WriteLn; 


WriteString(narae); WriteString(”!”); 


WriteString(”Wir wünschen Ihnen viel Preude”); 
WriteLn; 

WriteString(”beim Durcharbeiten dieses Buches.”); 
WriteLn; WriteLn; 


WriteString(”Noch einmal (j/n) : 




Read(antwort); 




UNTIL antwort = ”n” 


(* .: 

,. bis ’antwort’ = "n” ist *) 


END ZweitesBeispiel. 


Hier wird der Benutzername (Variable name) und später (gegen Ende) ein einzelnes Zeichen 
(antwort) eingegeben. Um ein einzelnes Zeichen zu speichern, braucht man eine Variable 
vom Datentyp CHAR (engl, character = dt. »Zeichen«). Die Zeichenkette name besteht aus 
mehreren Zeichen (im Beispiel maximal 80). Man spricht von einem »Feld« von 80 Zeichen. 
Die Zeichen sind durchnumeriert, hier von 0 bis 79 (macht 80). Also definiert man in Modula 

VAR name: ARRAY [0..79] OP CHAR. 

Die Zeichenkettenvariable name wird mit der Prozedur ReadString eingegeben. An dieser 
Stelle soll der Benutzer seinen Namen eintippen, der dann als Inhalt in der Variable name 
steht. Für das Einlesen eines einzelnen Zeichens nimmt man die Prozedur Read. Es läuft wie¬ 
der eine Schleife ab, diesmal aber solange, bis der Benutzer ein »n« für nein eintippt. Es handelt 
sich um eine »wiederhole < B/ock >bis < Bedingung>- Schleife« oder in Modula REPEAT< Block> 
UNTIL <Bedingung >. Der <Block> wird wiederholt, bis die Bedingung erfüllt ist. An dem klei¬ 
nen Programm erkennt man, daß zwischen zwei Anweisungen ein Semikolon als Trennzei¬ 
chen gesetzt wird. Vor END und UNTIL darf es entfallen. 

Im nächsten (und letzten) Einführungsbeispiel wollen wir den »größten gemeinsamen Teiler« 
(ggT ) zweier einzugebenden natürlichen Zahlen i und j berechnen lassen: 
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MODULE DrittesBeispiel; 

PROM InOut IMPORT ReadCard, WriteCard, WriteString, WriteLn, Read; 

VAR i,o,ggT : CARDINAL; 
antwort : CHAR; 

BEGIN 

WriteString("Programm zur Berechnung des größten ”); 
WriteString(”gemeinsamen Teilers (ggT) zweier Zahlen”); 

REPEAT 

WriteLn; WriteLn; 

WriteString(”Geben Sie die erste Zahl ein: ”); ReadCard(i); 
WriteString(”Geben Sie die zweite Zahl ein: ”); ReadCard(j); 

WEILE i # j DO 

IP i > j THEN i := i - j ELSE j := J - i END (* ggT errechnen *) 

END; 

ggT := i; 

WriteString(”Der ggT dieser Zahlen lautet: ”); 

WriteCard(ggT,6); 

WriteLn; WriteLn; 

WriteString("Wünschen Sie noch eine Berechnung (j/n)? ”); 

Read(antwort); 

antwort := CAP(antwort); (* Umwandlung in Großbuchstaben *) 

UNTIL antwort = ”N”; 

END DrittesBeispiel. 


Das Programm ist schon etwas luxuriöser. Es schreibt zunächst eine Überschrift. Dann kann 
man die beiden Zahlen i und j eingeben (mit ReadCard, etwa »Lese Zahl vom Typ CARDINAL«). 
Danach wird der ggT berechnet. Das Ergebnis wird mit WriteCard ausgegeben. 

WriteCard(ggT, 6) bedeutet, daß ggT in einem Feld der Länge 6 rechtsbündig ausgegeben 
wird. Eventuell werden Leerzeichen vorangestellt. Hat die Zahl mehr als 6 Stellen, wird sie 
trotzdem vollständig ausgegeben. In Megamax-Modula erzeugen alle Eingabe-Prozeduren 
wie ReadCard (außer der Prozedur Read) einen Zeilenvorschub. Bei anderen Modula-Sy- 
stemen ist das nicht der Fall. Sie müssen noch WriteLn im Programm dahintersetzen, damit 
der Bildschirm einigermaßen vernünftig aussieht! 

Damit unsere Schleife auch abbricht, wenn der Benutzer sowohl ein kleines »n« als auch ein 
großes »N« eingibt, wandeln wir das gelesene Zeichen antwort mittels der Standardfunktion 
CAP in einen Großbuchstaben um; wir brauchen dann nur noch auf »N« zu testen. Bleibt 
noch die eigentliche Berechnung des ggT zu erklären: 
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Wenn die beiden Zahlen i und j gleich sind, ist der ggT schon gefunden, nämlich i (oder j, sie 
sind ja gleich). Wenn i und j ungleich sind (in Modula: i# j oder i<> j ), zieht man die kleinere 
Zahl von der größeren Zahl solange ab, bis diese Gleichheit erreicht ist. Also: 

Palls i > j, dann neues i durch i - j ersetzen, 
sonst neues j durch j - i ersetzen. 

Für die Umsetzung in Modula werden die englischen Wörter »IP« (für »falls«) und »ELSE« 
(für »sonst«) benutzt. 

Die Ersetzung von i durch i - j nennt man eine »Zuweisung«. Das Zeichen dafür ist 
»: =«, lies »wird zu«. Die Schleife, die diese iP-Anweisung umfaßt, soll zu Beginn die Bedin¬ 
gung i# j prüfen, hierzu dient die Wiederholungsanweisung: 

WHILE <Bedingung> DO <Anweisungen> END 

Etwa: solange Bedingung erfüllt, führe Anweisungen aus. 

Ein solches Rezept wie dieses Beispiel zur Ermittlung des ggT nennt man einen »Algorith¬ 
mus« (etwa: »Bearbeitungsvorschrift«). Das Erstellen von Algorithmen und die Prüfung auf 
ihre Korrektheit ist eine wichtige Aufgabe in der Informatik. Der ggT-Algorithmus funktio¬ 
niert dann nicht, wenn entweder für i oder j eine 0 (Null) eingegeben wurde, da dann in der 
Schleife die Zahlen nicht kleiner werden und so die Gleichheit nicht erreicht wird. Die Schleife 
würde bei einer solchen Eingabe nicht zum Ende kommen. Da bleibt dann nur noch der Griff 
zum Reset-Knopf! Solche Fehleingaben müssen in einem professionellen Programm durch 
bessere Eingabeprozeduren verhindert werden. 

Nach diesen Beispielen tauchen bestimmt einige Fragen auf, etwa: 

• Wie sieht allgemein die Struktur eines Moduls aus? 

• Wie dürfen Bezeichner aussehen (aus welchen Zeichen dürfen sie bestehen)? 

• Welche »elementaren« Datentypen gibt es in Modula (zum Beispiel CHAR, CARDINAL) und 
wie kann man daraus weitere Datentypen gewinnen (»strukturierte Datentypen«, zum 
Beispiel ARRAY [0. .79] OP CHAR)? 

• Welche reservierten Wörter gibt es in Modula (zum Beispiel M0DULE, IMPORT, END)? 

• Über welche Standardprozeduren verfügt Modula (zum Beispiel CAP)? 

• Welche Wiederholungsanweisungen (Schleifen, zum Beispiel REPEAT... UNTIL) und wel¬ 
che bedingten Anweisungen (zum Beispiel IP... THEN... ELSE) gibt es? Wiederholungsan¬ 
weisungen und bedingte Anweisungen kontrollieren den Programm-Ablauf. Sie werden 
daher unter dem Oberbegriff »Kontrollstrukturen« zusammengefaßt. 
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• Mit welchen Operatoren (zum Beispiel +,: = ,#, = ) arbeitet man in Modula? 

• Welche Bibliotheksmodule (zum Beispiel inOut) liefert ein Modula-System? 

Antworten darauf geben die nächsten Abschnitte. Darüber hinaus folgen weitere Beispiele mit 
neuen Algorithmen. 

Nun kann man eine Spracheinfiihrung sicherlich so gestalten, daß man den Leser von Pro¬ 
grammbeispiel zu Programmbeispiel führt und immer weitere Besonderheiten erklärt. Das 
kann sicherlich recht kurzweilig sein (oder auf die Dauer langweilig), aber der Leser erhält kei¬ 
nen Überblick. Die Sprachbeschreibung gerät umfangreich. Alternativ hierzu könnte man 
zunächst einen Überblick geben, damit der Anfänger schon einmal mit dem groben Rahmen 
vertraut gemacht wird. Dabei wird vielleicht nicht sofort alles klar; es müssen Anwendungs¬ 
beispiele folgen. Diese Methode erfordert jedoch anfangs eine höhere »Frustrationstoleranz« 
beim Leser. Dafür ist sie aber schneller, kompakter und man hat gleich in der Übersicht etwas 
zum Nachschlagen. 

Aus dieser nicht unbedingt objektiven Beschreibung beider Methoden dürfte klar geworden 
sein, daß wir im Unterschied zu den meisten Computer-Büchern den zweiten Weg einschlagen. 
Es folgt also jetzt eine »geballte Ladung« von Listen (Schlüsselwörter, Standardtypen, Opera¬ 
toren usw.). Sie können sich anschließend bei den zahlreichen Programmbeispielen wieder er¬ 
holen. Statt wie in anderen Einführungsbüchern die Sprachbeschreibung auf etwa 300 Seiten 
auszudehnen, wollen wir mit deutlich weniger auskommen und noch etliches für die profes¬ 
sionelle Programmierung an den Mann/die Frau bringen. 


1.1.3 Syntaxdiagramme 



Bild 1.6: Syntaxdiagramm Gleisplan 
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Betrachten wir folgenden Gleisplan: 

Ein von links kommender Zug passiert auf jeden Fall A-Stadt, den Tunnel und B-Stadt (Se¬ 
quenz oder Zusammensetzung), hat dann die Möglichkeit, entweder C-Stadt oder D-Stadt zu 
passieren (Selektion oder Auswahl), kann dann E-Stadt durchqueren oder an ihr vorbeifahren 
(Option) und dann an der letzten Weiche das ganze beliebig oft (oder gar nicht) wiederholen 
(Iteration oder Wiederholung). 

Eine mögliche Zugfahrt wäre also -»A-Stadt -»TUNNEL -»B-Stadt -»D-Stadt -»A-Stadt 
-»TUNNEL -»B-Stadt -»C-Stadt ->E-Stadt -» 

Das Kästchensymbol A-Stadt könnte wieder so aussehen: 


A-Stadt 



Bild 1.7: A-Stadt 

Sie werden bemerkt haben, daß wir eckige und abgerundete Symbole benutzt haben. Die abge¬ 
rundeten Symbole sind nicht weiter zu gliedernde Einheiten. Man spricht von Terminalsym¬ 
bolen. Ein eckiges Symbol muß aber noch weiter gesondert beschrieben werden. (Non-ter- 
minal-Symbol). Es stellt also einen Verweis auf einen weiteren Gleisplan dar. Diese Beschrei¬ 
bung kann in mehreren Stufen geschehen, bis man schließlich auf Terminalsymbole trifft. 

Eigentlich wollten Sie ja nicht Eisenbahner werden, sondern Modula lernen. Aber genau mit 
diesen »Eisenbahndiagrammen« läßt sich die Sprache Modula beschreiben! Man spricht hier 
nur vornehmer von »Syntaxdiagrammen«, da sie den Satzbau der Sprache festlegen. 

Die Terminalsymbole sind dabei einzelne Zeichen wie Klammer, Satzzeichen, Buchstaben, 
Ziffern und die Schlüsselwörter der Sprache (zum Beispiel MODULE, BEGIN, END). Sie können 
nun die Syntaxdiagramme lesen, denn außer den oben geschilderten Fällen Sequenz, Selek¬ 
tion, Option und Iteration kann nichts weiteres Vorkommen. Beachten Sie aber, daß die 
»Züge« nur einen Vorwärtsgang haben. Die Form der »Weichen« ist also wichtig; die Pfeile 
verschaffen zusätzliche Klarheit. Als Beispiel das Syntaxdiagramm der WHILE-Schleife: 
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—» ^WHILE ^ —► Expression 39 — DO ^ ^ 

CT“ ." ' 


StatementSequence 14 —e ^ENd) —► 


SYNTAX: “WhileStatement“(49) 

Man sieht die Schlüsselwörter WHILE, DO und END. »Expression« (Ausdruck) und »State¬ 
mentSequence« (Anweisungsfolge) sind noch näher zu beschreiben. Dies ist für die Anwei¬ 
sungsfolge einfach: 


o 







1 W 

Statement 45 

1 




SYNTAX: “StatementSequence“(14) 

Die Detailbeschreibung ist noch nicht zu Ende. Wir brechen hier aber ab, da die Benutzung der 
WHILE-Schleife ersichtlich ist: 

WHILE <Bedingung> DO 
<Anweisungl >; 

<An weis ung2>\ 

<Anweisung3 >; 

<Anweisung4> 

END 

Wir werden an einigen Stellen der Spracheinführung von Syntaxdiagrammen Gebrauch ma¬ 
chen, oft aber auch eine Erläuterung an Programmbeispielen vorziehen. Der Anhang B listet 
alle Syntaxdiagramme auf. Er dient also als Ratgeber in Zweifelsfragen. 

Abschließend sei noch erwähnt, daß Syntax-Diagramme keine Spielerei oder nur ein didakti¬ 
scher Trick sind. Sie legen genau die Sprachdefinition fest, daher arbeitet auch der Compiler 
bei der Übersetzung ihrer Modula-Quelltexte danach. Bildlich gesprochen prüft er ab, ob der 
»Zug« nach dem Gleisplan fahrt und erzeugt für die einzelnen »Gleise« und »Tunnel« den ent¬ 
sprechenden Code, den der Computer dann ausführen kann. 
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1.2 Übersichten 


1.2.1 Die Struktur eines Modula-Programms 


Wie die einführenden Beispiele gezeigt haben, besteht ein Modula-Programm aus drei Teilen: 

I. dem Modulkopf 

II. den Importlisten 

III. dem Programmblock 

Zu I. (Modulkopf) 

Der Modulkopf besteht aus dem Schlüsselwort M0DULE, gefolgt von einem Modulnamen (Be¬ 
sonderheiten später). Ein Modulname ist ein »Bezeichner« (ebenso wie ein Variablen-Be- 
zeichner). Für Bezeichner gelten folgende Regeln: 

1. Bezeichner bestehen aus Buchstaben (»A« bis »Z« und »a« bis »z«) und Ziffern (»0« bis 
»9«). 

2. Das ersten Zeichen muß ein Buchstabe sein. 

3. Groß- und Kleinbuchstaben werden unterschieden. 

4. Es gibt keine Längenbeschränkung für Bezeichner (Bezeichner können beliebig lang sein). 

5. Es dürfen keine Modula-Schlüsselwörter (siehe unten) als Bezeichner verwendet werden. 

Oder kürzer als Syntax-Diagramm (Buchstabe und Ziffer wird nicht weiter aufgeschlüsselt, da 
klar ist, was gemeint ist): 



SYNTAX: “ Ident“(l.) 

In manchen Fällen reicht die Angabe eines Bezeichners nicht aus, um ihn eindeutig zuzuord¬ 
nen. Wir geben ein Beispiel: Die Prozedur Read findet man sowohl im Modul inOut als auch 
im Modul Terminal (InOut ist etwas komfortabler). Sollte ein Programm beide Read-Pro- 
zeduren brauchen, so reicht der Name Read im Programm nicht zur eindeutigen Identifika¬ 
tion aus. Man behilft sich folgendermaßen: 
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Die Importliste lautet einfach: 

IMPORT InOut; 

IMPORT Terminal; 

Beide Module beinhalten eine Prozedur Read. Im Programm benutzt man sie dann mit 
InOut. Read bzw. Terminal. Read. Man spricht hier von einem »qualifizierten« Bezeichner 
(von engl, qualify = einschränken, näher bestimmen). Einem Bezeichner b wird dabei ein wei¬ 
terer Bezeichner a mit einem Punkt vorangestellt zu a. b. 



Ident i 



Ident i 


SYNTAX: “Qualldent“(2) 

Beispiele für gültige Bezeichner: 

i 

xHoch2 

ZweitesBeispiel 
UndNunEinLangerBezeichner 

y- z 

x. y. z 

Wie man am letztem Beispiel sieht, kann ein bereits qualifizierter Bezeichner y. z wiederum 
qualifiziert werden. 

Keine gültigen Beispiele sind: 

2x (Ziffer am Anfang) 

Zweites Beispiel (Leerzeichen sind nicht erlaubt) 

Zweites_Beispiel (Sonderzeichen sind nicht erlaubt) 

Überschrift (Umlaute sind keine zulässigen Buchstaben) 

Zu II. (Importlisten) 

Importlisten haben die folgende Gestalt: 

PROM <Modulbezeichner> IMPORT <Bezeichnerl >, <Bezeichner2>. ..; 
oder 

IMPORT <ModulbeZeichner>, <Modulbezeichner>. . . ; 
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In der ersten Form (Import mit FROM) stehen Bezeichner 1 und Bezeichnet^ für Konstanten 
(siehe unten), Datentypen, Variablen oder Prozeduren (siehe unten) aus diesem Modul. Meh¬ 
rere Bezeichner werden also durch Kommata getrennt; am Ende steht ein Semikolon. 

Bei der zweiten Form (Import ohne »FROM«) werden nur die Modulnamen importiert. Will 
man die Bezeichner dieser Module ansprechen, müssen sie mit dem Modulnamen qualifiziert 
werden: 

<Modulname>. <Bezeichner> 

Zu III. (Programmblock) 

Der Programmblock besteht aus 

1. Deklarationsteil und 

2. Anweisungsteil. 

Im Deklarationsteil werden Programmbestandteile wie Konstanten, Datentypen und Varia¬ 
blen deklariert, aber auch Unterprogramme, sogenannte »Prozeduren« oder »lokale Mo¬ 
dule«. 

Anders als in Pascal gibt es hier keine strenge Reihenfolge! 

Die meisten Compiler akzeptieren jedoch nicht eine völlig beliebige Reihenfolge: so muß zum 
Beispiel eine Variable vor ihrer Benutzung deklariert sein. 

Der Anweisungsteil beginnt immer mit dem Schlüsselwort BEGIN und endet immer mit END 
<Modulname>. 

Zwischen BEGIN und END werden dann die Anweisungen, die das Programm später ausfüh¬ 
ren soll, in der Reihenfolge aufgelistet. 


1.2.2 Reservierte Wörter der Sprache 

Im folgenden geben wir eine alphabetische Liste der 40 reservierten Wörter und erklären 
knapp ihre Bedeutung. Hier wird natürlich noch nicht alles in voller Klarheit ausgebreitet; die 
Einzelheiten gehen aus den nächsten Abschnitten hervor! 

AND logischer Operator: »UND« 

ARRAY Typdeklaration: Feld 

BEGIN leitet den Anweisungsteil eines Moduls oder einer Prozedur ein 

dient zur Angabe der Schrittweite bei einer FOR-Schleife 


BY 
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CASE 

Fallunterscheidung oder varianter Record 

CONST 

Einleitung einer Konstantendeklaration 

DEFINITION 

Einleitung eines Definitionsmoduls 

DIV 

Operator: Ganzzahlige Division 

DO 

Bestandteil einer FOR- oder WHILE-Schleife 

ELSE 

Bestandteil einer IF-Anweisung 

ELSIF 

Bestandteil einer IF-Anweisung 

END 

begrenzt einen Block, eine Prozedur oder einen Modul 

EXIT 

Abbruch einer LOOP-Schleife 

EXPORT 

leitet bei lokalen Modulen die Exportliste ein 

FOR 

Einleitung einer FOR-Schleife 

FROM 

Schlüsselwort in Importlisten 

IF 

Einleitung einer Verzweigung 

IMPLEMENTATION 

Einleitung eines Implementationsmoduls 

IMPORT 

Schlüsselwort in Importlisten 

IN 

logischer Operator für Mengen (»ist Element aus«) 

LOOP 

Einleitung einer LOOP-Schleife 

MOD 

Operator: Modulus (Rest bei der ganzzahligen Division) 

MODULE 

Einleitung eines Moduls 

NOT 

logischer Operator: »nicht« 

OF 

Bestandteil einer Felddeklaration: ARRAY OF... 

OR 

logischer Operator: »oder« 

POINTER 

Typdeklaration: Zeiger 

PROCEDURE 

Einleitung eines Unterprogramms (Prozedur); auch zur Typdekla¬ 
ration eines Prozedur-Typs 

QUALIFIED 

Schlüsselwort in Export-Listen: EXPORT QUALIFIED... (qualifizier¬ 
ter Export: erzwingt Qualifizierung der exportierten Bezeichner) 
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RECORD 

Typdeklaration: Verbund 

REPEAT 

Einleitung einer REPEAT-Schleife 

RETURN 

beendet eine Prozedur, liefert bei Funktionsprozeduren gleichzeitig 
den Rückgabewert 

SET 

Typdeklaration: Menge 

THEN 

Bestandteil einer IF-Anweisung 

TO 

Bestandteil einer FOR-Schleife oder Zeigerdeklaration 

TYPE 

Einleitung von Typdeklarationen 

UNTIL 

Bestandteil einer REPEAT-Schleife 

VAR 

Einleitung von Variablendeklarationen 

WHILE 

Einleitung einer WHILE-Schleife 

WITH 

dient zur Dereferenzierung von Variablen vom Typ RECORD 


Diese Schlüsselwörter sind nicht zu verwechseln mit den Bezeichnern der Standardtypen oder 
Standardprozeduren von Modula, die ebenfalls alle groß geschrieben werden. 

1.2.3 Übersicht über die Standard-Datentypen 

Ebenso wie man aus der Mathematik natürliche Zahlen (positive und negative) und reelle 
Zahlen (die mit dem Komma) kennt, gibt es in Modula auch verschiedene Zahlentypen. Dazu 
kommen noch Zeichen, Wahrheitswerte und Mengen als einfache Datentypen: 


Bezeichner Datentyp 


INTEGER 

LONGINT 

CARDINAL 

LONGCARD 

REAL 


ganze Zahl 
ganze Zahl 
natürliche Zahl 
natürliche Zahl 
Bruchzahl 


Größe in Byte 

2 

4 

2 

4 

4 oder 8 


Wertebereich 

-215. .215-1 
-231. .231-1 
0..2i 6 -l 
0..232-1 
siehe unten 
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Bezeichner 

Datentyp 

Größe in Byte 

Wertebereich 

LONGREAL 

Bruchzahl 

8 

siehe unten 

CHAR 

Zeichen 

1 oder 2 

CHR(0)..CHR(255) 

BOOLEAN 

Wahrheitswert 

1 oder 2 

FALSE, TRUE 

BITSET 

Bit-Menge 

2 

SET OF [0..15] 


Die Größe der Datentypen und damit der Wertebereich hängt vom verwendeten Compiler ab. 
Unterschiede ergeben sich bei den Typen BOOLEAN, CHAR, REAL und LONGREAL: 

Für BOOLEAN und CHAR reicht ein Byte, manche Compiler belegen aber zwei Bytes. Die mei¬ 
sten Modula-Compiler (zum Beispiel Hänisch, TDI, SPC...) implementieren REAL mit 4 Byte 
und LONGREAL mit 8 Byte. Megamax-Modula und MSM2 stellt nur den Typ REAL zur Ver¬ 
fügung, aber gleich mit 8 Byte. Ein 8-Byte-Real besitzt im allgemeinen eine größere Genau¬ 
igkeit und einen größeren Wertebereich als mit nur 4 Byte; aber auch dies ist von der jeweiligen 
Implementation abhängig. Ein Megamax-REAL besitzt beispielsweise eine Genauigkeit von 
ca. 13 Stellen bei einem Wertebereich von - IO 1233 bis + 10 1233 . 

Einige dieser T ypen lassen sich unter dem Begriff »skalare T ypen« zusammenfassen. Zu diesen 
Typen zählen die Standardtypen INTEGER, LONGINT, CARDINAL, LONGCARD, CHAR und 
BOOLEAN sowie die Aufzählungstypen (siehe 1.6.1). Ihnen ist gemeinsam, daß man alle ihre 
Werte aufzählen kann; ihre Werte sind quasi durchnumeriert. Die beiden Typen REAL und 
LONGREAL gehören nicht dazu. Skalare Typen zeichnen sich eben - wegen ihrer Aufzählbar¬ 
keit - durch folgende Eigenschaften aus: 

• Sie besitzen genau einen Vorgänger und einen Nachfolger. Damit lassen sich die Standard¬ 
prozeduren INC und DEC auf sie anwenden. 

• Man kann sie für Laufvariablen in FOR-Schleifen und Selektoren in CASE-Anweisungen 
(Fallunterscheidung) benutzen. 

• Sie lassen sich (teilweise) als Indextyp für Felder verwenden (siehe Abschnitt 1.6.3). 

Aus diesen Standardtypen kann der Progammierer komplexere Datentypen, sogenannte 
strukturierte Typen bilden (zum Beispiel Felder). Hierzu der Abschnitt 1.6 
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1.2.4 Standardkonstanten in Modula 

Konstante 

Typ 

Bedeutung 

FALSE, TRUE 

BOOLEAN 

falsch, wahr 

NIL 

POINTER TO... 

Zeiger ins »Nichts« 

Zusätzlich bei Megamax-Modula: 



MaxCard 

CARDINAL 

216-1 

= 65535 

MaxLCard 

LONGCARD 

232-1 

= 4294967295 

Maxint 

INTEGER 

2>5-l 

= 32767 

Minlnt 

INTEGER 

-215 

=-32768 

MaxLInt 

LONGINT 

231-1 

= 2147483647 

MinLInt 

LONGINT 

-231 

=-2147483648 


Diese zusätzlichen Konstanten sind nicht erforderlich; die Werte lassen sich mit den Standard¬ 
funktionen MIN und MAX erhalten (s. u.). 


1.2.5 Übersicht über die Standardprozeduren 

In Modula gibt es nur 18 Standardprozeduren. Das sieht nach wenig aus, hat aber einerseits 
den Vorteil, daß man sich nicht viel merken muß, anderseits kann man ja beliebig viele Proze¬ 
duren aus Modulen importieren. 

Man unterscheidet Funktionsprozeduren (kurz: Funktionen) von Prozeduren im eigentlichen 
Sinne. Prozeduren führen bestimmte Anweisungen aus, Funktionen liefern darüber hinaus 
ein Ergebnis zurück, welches man einer Variablen zuweisen kann. Beispiel: 
chl:= CAP(ch2); 

ch2 heißt dabei »Argument« der Funktion CAP. 

ABS ( x ) absolute value , »Absolutbetrag« 

Funktion; liefert den Absolutwert (Betrag) des Arguments. Das Ergebnis ist 
vom gleichem Typ wie das Argument. Zugelassen sind INTEGER, LONGINT, 
REAL undLONGREAL. 

Beispiel: nach i: =ABS(-3) ist i gleich 3. 
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CAP(ch) 


CHR(i) 


DEC(x) 


DEC(x,n) 


EXCL(m,i) 


PLOAT(i) 


HALT 


Capital letter , »Großbuchstabe« 

Funktion; Argument und Ergebnis vom Typ CHAR. Konvertiert einen Klein¬ 
buchstaben in den entsprechenden Großbuchstaben. 

Beispiel: nach ch: =CAP( ,, a ,, ) ist ch gleich ”A” 

character , »Zeichen« 

Funktion; ergibt das Zeichen mit der Ordnungszahl i im ASCII-Zeichensatz 
(siehe Anhang D). Der Ergebnis-Typ ist CHAR, der Argument-Typ ist CARDINAL 
oder INTEGER. 

Beispiel: nach ch: =CHR(65) ist ch gleich ”A” 
decrease , »erniedrige, vermindere« 

Prozedur; ersetzt x durch seinen Vorgänger (den nächst kleineren Wert), x ist 
eine Variable beliebigen skalaren Typs. Wenn x vom Typ INTEGER ist, ent¬ 
spricht die Prozedur der Anweisung x: =x-l. 

Beispiele: 

nach c: =”D”; DEC(c); ist c gleich ”C” 
nach i: =5;DEC(i) ; ist i gleich 4. 

decrease , »erniedrige, vermindere« 

Prozedur; dekrementiert x um n; n ist dabei vom Typ CARDINAL. Ansonsten 
funktioniert DEC(x, n) wie ein n-maliger Aufruf von DEC(x). 

Beispiele: 

nach c: =”D”;DEC(c, 3); ist c gleich ”A” 
nach i: =5; DEC(i, 3); ist i gleich 2. 

exclude , »ausschließen« 

Prozedur; entfernt i aus der Menge m. i ist vom skalaren Typ T, die Menge 
vom Typ SET OF T. 

Beispiel: 

nach m: = {3, 4, 5, 6) ; EXCL(m, 4) ist m gleich {3, 5, 6}. 
floating point , »Fließkomma« (reelle Zahl) 

Funktion; Typ des Argumentes i ist standardmäßig CARDINAL (bei Megamax 
auch LONGCARD). FLOAT konvertiert i in die entsprechende REAL-Zahl. 
Beispiel: nach x: =FLOAT( 5) ist x = 5.0. 

halt, »beenden« 

Diese Prozedur beendet sofort die Programmausführung. Manche Systeme ge¬ 
ben nicht nur eine Fehlermeldung mit der Position des HALT aus, sondern ge¬ 
statten es noch, mit einem Debugger den Programmzustand zu untersuchen. 
Sehr nützlich bei Fehlersuche! 
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HIGH(a) 

highest index , »höchster Index« 

Funktion; a ist ein Feld (auch Open Array) ARRAY OF ... Das Ergebnis ist 
CARDINAL und liefert die Anzahl der Feldelemente minus 1. Das ist der höchste 
Index, wenn der kleinste 0 (Null) ist. 

INC(x) 

increase, »erhöhen« 

Prozedur; ersetzt x durch seinen Nachfolger (den nächst größeren Wert), x 
kann von jedem beliebigen skalaren Typ sein. Wenn x vom Typ INTEGER ist, 
entspricht die Prozedur der Anweisung x: =x+l. 

Beispiele: 

nach c: = ”D”; INC (c); ist ch gleich ”E” 
nach i: =5; INC(i); ist i gleich 6. 

INC(x,n) 

increase , »erhöhen« 

Prozedur; erhöht x um n; n ist dabei vom Typ CARDINAL. Ansonsten funktio¬ 
niert INC (x, n) wie ein n-maliger Aufruf von INC (x). Beispiele: 
nach c: =”D”; INC(c, 3); ist c = ”G” 
nach i: =5; INC(i, 3); ist i gleich 8. 

INCL(m,i) 

include , »einschließen« 

Prozedur; fügt i in die Menge m ein. i ist vom skalaren Typ T, wenn die 
Menge vom Typ SET OF T ist. 

Beispiel: 

nach m: ={3, 5, 6}; INCL(m, 4) ist m= (3, 4, 5, 6}. 

MAX(T) 

maximum , »Maximum« 

Funktion; ergibt den größten Wert des Typs T. T ist REAL, LONGREAL oder 
ein skalarer Typ. 

Beispiel: nach i: =MAX(CARDINAL) ist i gleich 65535. 

MIN(T) 

minimum , »Minimum« 

Funktion; ergibt den kleinsten Wert des Typs T; wie bei MAX ist T REAL, 
LONGREAL oder ein skalarer Typ. 

Beispiel: nach i: =MIN(CARDINAL) ist i gleich 0. 

ODD(i) 

odd , »ungerade« 

Funktion vom Typ BOOLEAN. i ist vom Typ INTEGER/LONGINT oder CAR- 
DINAL/LONGCARD. 

ODD liefert TRUE, falls i ungerade ist, und FALSE, falls i gerade ist. 
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ORD (x) ordinal number, »Ordnungszahl« 

Funktion; x ist von einem skalaren Typ, das Ergebnis ist CARDINAL. ORD(x) 
liefert das x-te Element in der Wertemenge des betreffenden Types von x. Das 
erste Element eines Aufzählungstypes hat die Ordinalzahl 0 (Null). 

Beispiel: nach i : = ORD (”A”) ist i gleich 65, da ”A” das Zeichen mit der 
Nummer 65 im ASCII-Zeichensatz ist. 

SIZE (x) size, »Größe« 

Funktion; ergibt die Anzahl der Bytes, die die Variable x belegt, x ist eine Va¬ 
riable beliebigen Typs, der Ergebnistyp ist CARDINAL(oderLONGCARD, z.B. bei 
Megamax). 

TRUNC (x) truncate , »abschneiden« 

Funktion; ergibt den ganzzahligen Anteil der REAL-Zahl x als CARDINAL (bei 
Megamax: LONGCARD). Die Nachkommastellen werden dabei »abgeschnitten«. 
Beispiel: nach i: =TRUNC(3. 9) ist i gleich 3. 

Die Ausführungen über die Standardprozeduren beziehen sich auf den Megamax-Compiler. 
Die anderen Compiler, die wir benutzt haben, folgen im großen und ganzen dieser Liste. Es 
gibt aber Abweichungen: 

1. Durch Spracherweiterungen: Etliche Systeme bieten über den Wirth-Standard hinausge¬ 
hende Prozeduren. 

2. Bei einigen Standardprozeduren sind andere Datentypen als in der obigen Liste erforder¬ 
lich. Dies gilt insbesondere für die Prozeduren DEC, FL0AT, HIGH, INC, SIZE und TRUNC. 

Bitte entnehmen Sie die Besonderheiten Ihrem Handbuch. Es würde den Rahmen unserer Ein¬ 
führung sprengen, wenn wir auf alle Einzelheiten der bekannten Compiler eingehen. Außer¬ 
dem entstünde hierdurch ein schlecht lesbarer Stil. Unsere Programmbeispiele wurden alle auf 
dem Megamax-System getestet. Dies hat den Vorteil, daß sich alle Programme durch ein ein¬ 
heitliches Design auszeichnen. 

Das war es schon, bleiben noch compilerspezifische Prozeduren: 

Bei SPC-Modula gibt es zusätzlich für die langen Typen noch 

FLOATD(i) Funktion; konvertiert den INTEGER/LONGINT Wert i in die entsprechende 
LONGREAL-Darstellung 

TRUNCD(x) Funktion; wandelt L0NGREAL x in eine entsprechende LONGINT-Zahl. 

Bei einigen Compilern (mit LONG-Typen) gibt es zusätzlich: 
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LONG(i) Funktion; wandelt den Wert i vom Typ INTEGER, CARDINAL, REAL oder 
WORD in den entsprechende LONG-Typen um 

SHORT (Li) Funktion; wandelt L0NGINT, L0NGCARD, L0NGREAL oder LONGWORD in den 
entsprechende kurzen Typ um. 

Bei SPC-Modula findet man diese beiden Funktionen im Modul SYSTEM. 

Hänisch-Modula entspricht bei etlichen Prozeduren nicht dem obigen Standard. Das hat sei¬ 
nen Grund darin, daß CARDINAL und INTEGER wahlweise 2 Byte oder 4 Byte belegen können. 
Die Typen der Standardprozeduren sind entsprechend flexibel. Außerdem verfügt Hänisch- 
Modula noch über Prozeduren zur Stringbehandlung, die normalerweise von einem Modul 
Strings importiert werden müssen. 

Wie an diesem Abschnitt zu sehen ist, gibt es leider Abweichungen je nach verwendetem Com¬ 
piler. Inkompatibilitäten bereiten stets den größten Frust beim Programmieren. Fluchen Sie 
also nicht gleich, wenn Ihr Compiler beim Übersetzten der Quelltexte unserer Diskette etwas 
anmeckert. Die Programme wurden sorgfältig mit dem Megamax-Compiler der Version 3.6 
entwickelt. Für die beiden ersten Kapitel wurde Wert darauf gelegt, möglich wenig System¬ 
eigenheiten zu benutzen. 

Wenn Ihren Compiler also etwas stört, so wird es an den oben genannten Differenzen liegen. 
Schauen Sie deshalb in Ihr Handbuch, welchen Datentyp zum Beispiel HIGH oder TRUNC lie¬ 
fert. Durch kleine Änderungen in diesem Bereich sollten Sie unsere Programme stets zum 
laufen bringen. Die Aussagen dieses Buches beziehen sich auf den Stand von Anfang 1989. In 
Zweifelsfällen sollten Sie also aktuelle Informationen zu Ihrem System zu Rate ziehen, da die 
Dinge noch im Fluß sind. Aus diesem Grunde lohnt es sich nicht, mit einer Raubkopie zu ar¬ 
beiten. 

Unterschiedlichkeiten einzelner Dialekte gibt es auch in anderen Sprachen. Im Gegensatz zu 
Basic oder Pascal ist Modula noch hoch kompatibel. Dies zeigt sich zum Beispiel daran, daß 
wir Module des Kapitels 5 auf einem anderen Rechner entwickelt haben. 

Die genannten Unterschiede dürften sich noch weiter verringern, wenn für Modula eine Stan¬ 
dardnorm vorliegt. Die Internationale Standardisierungs-Organisation ISO befaßt sich seit 
mehreren Jahren mit der Normierung von Modula-2. Es wird damit gerechnet, daß diese 
Norm Ende 1989 vorliegt. Der Hersteller von SPC-Modula hat bereits versprochen, sich die¬ 
ser Norm anzuschließen. Es ist zu hoffen, daß andere Systeme dies auch tun werden. Bis dahin 
gilt: »Vive la difference«. 
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1.2.6 Operatoren und Begrenzer 

In Modula finden folgende Sonderzeichen bzw. Symbole Verwendung: 


Zeichen Bedeutung 


/ 

& 

# 

<> 


( ) 

[ ] 

{ } 

(* *) 


Addition; auch Vereinigung von Mengen 

Subtraktion; auch Differenz von Mengen 

Multiplikation; auch Schnitt von Mengen 

Division; auch »symmetrische Differenz« von Mengen 

Zuweisung (lies »wird zu« oder »definitionsgemäß gleich«) 

logisches »Und«, gleichbedeutend mit AND 

logisches »Nicht«, gleichbedeutend mit NOT 

ungleich 

wie #: ungleich 

kleiner 

kleiner oder gleich 
größer 

größer oder gleich 

Klammern (Vorrang in Ausdrücken) 

Indexklammern 
Mengenklammern 
Kommentarklammern 
Dereferenzier-Operator (für Zeiger) 

Satzzeichen 


1.2.7 Übersicht für Aufsteiger von Pascal 

Dieser Abschnitt ist für erfahrene Pascal-Programmierer gedacht. Da Modula ein Nachfolger 
von Pascal ist, gibt es viele Übereinstimmungen, so daß hier nur die unterschiedlichen Sprach- 
elemente aufgezeigt werden. Dies gibt dem Pascal-Progammierer eine schnelle Einstiegs¬ 
möglichkeit, so daß weite Teile des gesamten ersten Kapitels »diagonal« gelesen werden kön¬ 
nen. Ausnahmen bilden jedoch die Abschnitte 1.3, 1.4, 1.5.3,1.6.7,1.7 und 1.8, die Elemente 
jenseits von Pascal enthalten. 
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Wenn Sie sich nicht in Pascal heimisch fühlen, sollten Sie diesen Abschnitt überschlagen und 
das restliche erste Kapitel gründlich durcharbeiten. 

Was ist neu in Modula gegenüber Pascal? 

Schreibweise 

Es wird streng zwischen Groß- und Kleinschreibung unterschieden. So sind zahl, ZAHL und 
Zahl verschiedene Bezeichner. Der Unterstrich »_« ist in Bezeichnern nicht zulässig (auch 
wenn ihn manche Compiler auf dem Atari durchgehen lassen). 

Kommentare 

dürfen nur in (*. . . *) eingeschlossen sein, geschweifte Klammern ({...}) sind für Mengen 
reserviert. Kommentare dürfen geschachtelt sein. 

Programmstruktur 

Ein Programm beginnt mit dem Schlüsselwort M0DULE (statt PROGRAM), dann können Im¬ 
portlisten folgen. 

Deklarationsteil 

Im Deklarationsteil können Konstantendeklarationen, Variablendeklarationen und Proze¬ 
durdeklarationen in beliebiger Reihenfolge und an beliebiger Stelle erfolgen. Variablendekla¬ 
rationen können zum Beispiel am Anfang des Programms und dann noch mehrmals mitten¬ 
drin erfolgen. Das gleiche gilt für die anderen Deklarationen. 

Die meisten Modula-Compiler auf dem Atari (die Single-pass-Compiler, die den Programm¬ 
text nur einmal durchlaufen) sehen jedoch eine Einschränkung vor: Bei ihnen muß jeder Be¬ 
zeichner vor seiner Verwendung deklariert sein (Ausnahme: Pointer-Deklarationen). Bei die¬ 
sen Compilern sind allerdings bei Prozeduren FORWARD-Deklarationen erlaubt. Bei der eigent¬ 
lichen Definition der Prozedur muß die komplette Parameterliste wiederholt werden. 

Standardbezeichner sind überall definiert. Importierte Bezeichner sind nach dem IMPORT de¬ 
finiert, wenn sie in der Importliste erscheinen; ansonsten (Import ohne FROM) müssen sie bei 
der Benutzung qualifiziert werden. 

Datentypen 

Neu sind CARDINAL (positive Ganzzahlen mit Null) und BITSET (entspricht SET 0F 
[0. . 15]). Die meisten Compiler verfügen über doppelt lange Zahlentypen: 
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• LONGCARD 

Ganze Zahlen von 0 bis 4294967295 

• LONGINT 

Ganze Zahlen von -2147483648 bis 2147483647 

• LONGREAL 

REAL mit größerer Genauigkeit/Wertebereich 


Konstantendeklarationen 


enthalten ihren Typ in den meisten Fällen implizit: 


c=15; 

c=17B; 

c=OFH; 

c=15D; 

c=-15D; 

r=4.0; 

ch=”A”; 

ch=101C; 

s=”Alles klar” 


CARDINAL-Konstante 

oktale CARDINAL-Konstante (17 okta , = 15 dezimal ) 
hexadezimale CARDINAL-Konstante (das erste Zeichen muß eine Zif¬ 
fer sein) 

LONGCARD-Konstante 

LONGINT-Konstante 

oder r=4. ; REAL-Konstante (immer mit Punkt) 
oder c= ’A’; CHAR-Konstante 
CHAR-Konstante (ASCII-Wert oktal!) 
oder s=’Alles klar’ String 

Der String darf durch beide Arten von Anführungsstrichen (einfa¬ 
che und doppelte) begrenzt sein. Am Anfang und Ende muß aber der 
gleiche stehen; der andere darf dann im String Vorkommen. 


s = ”Der ’Freak’ ”oder s = ’ Der”Freak’” 
m= {1. . 3} ; Menge vom Typ BITSET; 

Bei anderen Mengen als BITSET muß der Typ mitangegeben wer¬ 
den. 


TYPE VierMenge=SET 0F [1..4]; 
C0NST m=VierMenge{1. . 3}; 


Typdeklarationen 

Unterschiede gibt es nur bei 

a) Unterbereichstypen 

b) Mengen 

c) Varianten Verbunden 

d) Zeiger (»Pointer«) 

e) Prozedur-Typen (gibt’s in Pascal nicht) 
0 Dateien (»Files«) 

g) Zeichenketten (»Strings«) 
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Zu a) Unterbereichstypen 

Statt (Pascal): Unterbereich=A. . Z 

schreibt man in Modula: Unterbereich= [A. . Z]. Der Ausdruck [0. . 99] ist ein 
Unterbereich des Types CARDINAL, hingegen ist INTEGER [ l. . 99] ein Unterbereich 
des Types integer. 

Zu b) Mengen 

Mengen dürfen nicht beliebig groß sein. Auf dem Atari sind im allgemeinen nur 16 
Elemente erlaubt. Damit sind Mengen wie SET OP CHAR nicht möglich. Einige Com¬ 
piler (TDI, Megamax) lassen aber Mengen bis 65535 Elementen zu. 

Zu c) Varianten Verbunden 

Entnehmen Sie die Änderungen bitte dem Abschnitt 1.6.4. 

Zu d) Pointer 

Statt (Pascal): 

TYPE Zeiger=~REAL schreibt man in Modula: 

type Zeiger=P0INTER TO REAL, was wesentlich lesbarer ist. 

Zu e) Prozedur-Typen 

Den Datentyp PROCEDURE gibt es in Pascal nicht. Er wird in Abschnitt 1.6.7 ausführ¬ 
lich beschrieben. 

Zu 0 Files 

Es gibt in Modula keinen Standard-Datentyp EILE. Er wird jedoch in Modulen wie 
PileSystem, Piles oder Streams realisiert. 

Zu g) Strings 

Den Datentyp STRING gibt es standardmäßig in Modula nicht (wohl in Hänisch-Mo- 
dula). Er wird in Modula mit ARRAY <Berei ch> OP CHAR realisiert. Stringprozedu¬ 
ren gibt es in einem Modul Strings. Die Stringlänge steht im Gegensatz zu Pascal 
nicht im vordersten Element. Vielmehr erkennt man das Ende eines Strings, der nicht 
alle Elemente belegt, am Abschlußzeichen OC. 

Prozedurdeklarationen 

Modula gestattet als Parameter von Prozeduren den sogenannten »offenen Feldtyp«: 
PROCEDURE p(feld: ARRAY OP T); 

Der Index läuft hier von 0 . . HIGH (feld ). Offene Felder sind nur in Parameterlisten zulässig, 
ansonsten ist stets wie in Pascal der Indexbereich mit anzugeben. 
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Funktionen hießen in Modula »Funktionsprozeduren« und werden auch durch das Schlüs¬ 
selwort PROCEDURE eingeleitet. In einer Funktionsprozedur erfolgt die Zuweisung des 
Funktionswertes durch RETURN. Beispiel: 

PROCEDURE quadrat(x: REAL): REAL; 

BEGIN 

RETURN x*x 
END quadrat; 


Bei dem Aufruf einer Funktionsprozedur ohne Parameter stehen Klammern: 
i:=rechne(); 

Als Ergebnistyp einer Funktion sind nur die Standard-Datentypen erlaubt. Die meisten 
Compiler gestatten jedoch Erweiterungen (zum Beispiel Verbünde). 

Ausdrücke 

In einem Ausdruck dürfen Variablen verschiedener Typen nicht miteinander vermischt wer¬ 
den. Operanden verschiedenen Typs müssen gegebenenfalls mittels Typkonvertierungs- 
Funktionen auf den Ergebnistyp transformiert werden. Hierzu dienen die Funktionen: 
TRUNC, PLOAT, INTEGER, CARDINAL oder dem Modul SYSTEM. 

Operatoren 

In Modula darf man anstelle von »<>« (ungleich) auch »#« schreiben. Für die logischen 
Operatoren AND und NOT darf man auch »&« bzw. »~« schreiben. 

Kontrollstrukturen 

1. LABEL- und GOTO-Anweisungen gibt es nicht. 

2. Anweisungen werden nicht mehr mit BEGIN und END geklammert. Dies ist auch nicht 
mehr erforderlich, da die Kontrollstrukturen selbst ein END erfordern. 

3. Modula kennt dieselben Schleifentypen wie Pascal. Hinzu kommt noch die LOOP- Schleife 
(vgl. 1.4.1). 

4. Geschachtelte IF-Anweisungen kann man in Modula mittels ELSIF ausdrücken: 

IF <bl> THEN <Anweisungenl> 

ELSIF <b2> THEN <Anweisungen2> 

ELSIF <b3> THEN <Anweisungen3> 
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ELSE <Anweisungen4> 


END; 


5. Die CASE-Anweisung hat eine leicht veränderte Syntax (vgl. 1.4.2) 


1.3 Vordefinierte Datentypen 


Wie schon die Eingangsbeispiele zeigten, braucht ein Programm Variablen und Daten 
(Zahlen, Zeichen, Zeichenketten, Wahrheitswerte). Die Variablen müssen im Deklarations¬ 
teil mit Namen und Typangabe vereinbart werden. Einige Beispiele zu Variablenvereinbarun- 
gen: 


VAR 


CHAR; 

ARRAY [0..79] OE CHAR; 
INTEGER; 

LONGCARD; 


antwort 

Vorname, Nachname 
Zaehler, Nenner 
GanzeZahl 


Man sieht, daß nach dem Schlüsselwort VAR eine Liste von Variablenbezeichnern, die durch 
ein Komma getrennt werden, folgt und dann nach einem Doppelpunkt eine Typbezeichnung. 
Das Ende markiert ein Semikolon. 

Basic-Aufsteigern mag eine Variablen-Deklaration überflüssig Vorkommen. Wozu dient sie 
überhaupt? 

• Sie legt einerseits die Namen der im Programm vorkommenden Variablen fest 

• und zum anderen deren Datentyp. 

Letzteres ist wichtig, da damit die interne Darstellung (wieviele Bytes belegt eine Variable?) 
und der Wertebereich der Variablen festgelegt wird. Die Deklaration 

VAR i: CARDINAL; 

beispielsweise beinhaltet, daß i nur ganzzahlige Werte mit 0 <i <65535 annehmen kann. 

Auf diese Weise kann der Compiler beim Übersetzen und das Laufzeitsystem beim Ablauf des 
Programmes überprüfen, ob i innerhalb dieses Bereiches liegt. 

Des weiteren werden durch die Typdeklaration auch die zulässigen Operatoren festgelegt. Der 
Divisionsoperator beim Typ CARDINAL heißt DIV, beim Typ REAL aber »/«. 

Man sieht also: Eine Variablen-Deklaration bringt Ordnung und Übersicht, sowohl für den 
Leser eines Programmes als auch für den Computer. 
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Noch eines zu den Variablen-Bezeichnern: Sie sollten so benannt werden, daß man aus ihren 
Namen ihren Verwendungszweck ableiten kann. Namen der Form i, x, y, z sind allenfalls 
für Hilfsvariablen brauchbar. 

Die nächsten Abschnitte machen genauer mit den Standard-Datentypen von Modula ver¬ 
traut: 

• CARDINAL / L0NGCARD 

• INTEGER / LONGINT 

• REAL / LONGREAL 

• BOOLEAN 

• CHAR 

• BITSET 


1.3.1 Der Datentyp CARDINAL 

Der Datentyp CARDINAL repräsentiert eine Teilmenge der natürlichen Zahlen und dient zum 
Zählen sowie für elementare Berechnungen. Genauer beinhaltet er die natürlichen Zahlen von 
0 bis 65535. Dieser Wertebereich benötigt rechnerintern einen Speicherplatz von 2 Byte oder 
einem »Wort«. 

Wir wollen uns kurz klarmachen, warum das so ist. Bekanntlich ist die kleinste Informations¬ 
einheit des Computers ein Bit, es kann die Werte 0 oder 1 annehmen. Mit zwei Bit lassen sich 
nun die vier Kombinationen 00, 01, 10, und 11 darstellen. Interpretiert man nun die letzte 
Stelle als »Einerstelle«, die davor als »Zweierstelle«, so bedeutet 

ll d üai : 1*2 + 1*1=3 genauer l*2 1 + 1*2° 

10 dU ai : 1*2 + 1*0=2 genauer 1*2 1 + 0*2° 

Die obigen 4 Zahlen sind also die Dual-Darstellung der Zahlen 0, 1,2, 3. 

Weiteren Stellen ordnet man nun höhere Zweierpotenzen zu: 


i 

2 6 

2 5 

2 4 

2 3 

2 2 

2 1 

2° 

0 

0 

1 

0 

0 

1 

0 

1 


Bild 1.8: Das Byte »00100101« 
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Die dargestellte Folge bedeutet also 

0 * 2 7 + 0 * 2 6 + 1 * 2 5 + 0 * 2 4 + 0 * 2 3 + 1 * 2 2 + 0 * 2 * + 1 * 2 ° 

=32+4+1 
= 37 

Acht Bit zusammen (wie oben dargestellt) nennt man ein Byte, das ist eine Speichereinheit Ih¬ 
res Atari. Nebenbei bemerkt hat ihr Atari 10458576 (Modell 1040 und ST 1), 2097152 (Modell 
ST2) oder 4194304 (Modell ST4) davon. 

Die höchste Zahl, die man mit einem Byte (also 8 Bit) darstellen kann ist also 

-^mmi-dual dezimal 

Mit einem Byte kann man also die Zahlen von 0 bis 255 darstellen; das sind 256 = 2 8 verschie¬ 
dene Zahlen. Sie können sich so klarmachen, daß man mit 2 Byte (also 16 Bit) 2 16 Zahlen dar¬ 
stellen kann (nämlich von 0 bis 2 16 -1), wobei die höchste Zahl 2 16 -1 = 65535 beträgt. 

Das ist der Maximalwert für CARDINAL-Zahlen! 

Welche Operationen und Standardprozeduren lassen sich auf CARDINAL-Zahlen anwenden? 

1. Zweistellige Operatoren: 

+ Addition 

Subtraktion 
* Multiplikation 

DIV ganzzahlige Division 
MOD Divisionsrest (Modulus) 

Zur Erläuterung von DIV und MOD ein Beispiel: 

Es ist 16 = 3 * 5 + 1; also gilt: 

16 DIV 3 ergibt 5, 

16 MOD 3 ergibt 1. 

Es gelten die üblichen »Vorfahrtsregeln« wie in der Mathematik: Die Operatoren *, DIV 
und MOD binden stärker als + und - (»Punktrechnung geht vor Strichrechnung«). Will 
man es anders haben, setzt man Klammern ein. 

2. Vergleichsoperatoren: 

<, >,<=,>=, =,#(oder<>) 

3. Auf CARDINAL anwendbare Standardprozeduren sind (vergleiche Abschnitt 1.2.5): ABS 
(Ergebnis = Argument, keine Wirkung), CHR, DEC, EXCL, FLOAT, INC, INCL, MAX, 
MIN, ODD, ORD (Ergebnis = Argument, keine Wirkung). 
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Einige Beispiele zum Umgang mit CARDINAL-Zahlen 

1) Die Anweisung 

IE a < b THEN Minimum : = a ELSE Minimum : = b END; 
berechnet das Minimum zweier CARDINAL-Zahlen a und b. 

2) Die nächste Anweisungsfolge berechnet den ggT (größter gemeinsamer Teiler) und das 
kgV (kleinste gemeinsame Vielfache) zweier Zahlen a und b nach dem Euklid’schen Al¬ 
gorithmus: 

VAR 

a, b : CARDINAL; 

ggT, kgV : CARDINAL; 
rest, ab : CARDINAL; 

ab : = a * b; 

REPEAT 

rest := a MOD b; 
a : = b; 
b := rest 
UNTIL rest = 0; 
ggT := a; 

kgV := ab DIV ggT; 


Überlegen Sie sich anhand von Zahlenbeispielen, wie dieser Algorithmus funktioniert und 
vergleichen Sie mit dem dritten Einführungsbeispiel! 

3) Das nächste Programmstück errechnet a b (für b^) (in Modula gibt es keinen Operator für 
»hoch«): 

VAR a, b, Ergebnis : CARDINAL; 

Ergebnis : = 1; (* Vorbereitung *) 

WHILE b > 0 DO Ergebnis := Ergebnis * a; DEC(b) END; 

Hier wird also die Potenz durch fortlaufendes Multiplizieren mit der Basis errechnet und 
der Exponent in jedem Schritt um 1 erniedrigt. Insgesamt sind b Multiplikationen nötig. 

4) Schneller läuft der folgende raffiniertere Algorithmus: 

VAR a, b, Ergebnis : CARDINAL; 
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Ergebnis := 1; (* Vorbereitung *) 

WHILE b > 0 DO 

IE ODD(b) THEN Ergebnis :■.» Ergebnis * a END; 
a : = a * a; 
b := b DIV 2 
END; 

Zur Erinnerung: ODD (b) bedeutet »b ist ungerade«. Es wird also fortlaufend die Basis qua¬ 
driert, der Exponent entsprechend halbiert. Machen Sie sich die Funktionsweise beider 
Algorithmen am Beispiel 2 10 klar! 

5) Berechnung der Fakultät von n (mathematische Schreibweise: n!), also des Terms 

n *(n-l) *(n-2)... 3 *2 *1; 
somit ist 

4! = 4*3*2* 1 = 24 

VAR Fakultaet, i : CARDINAL; 

Eakultaet := 1; (* Vorbereitung *) 

EOR i : = 1 TO n DO Eakultaet :» Fakultaet * i END; 

6 ) Das letzte Beispiel errechnet die Quersumme einer Zahl: 

Quersumme := 0; (* Vorbereitung *) 

WHILE n > 0 DO 

Quersumme := Quersumme + n MOD 10; 
n : = n DIV 10 
END; 

Folgendes sei dem Leser dringend empfohlen: 

• Wenn Sie keine oder nur wenig Programmiererfahrung haben, sollten Sie sich die Funk¬ 
tionsweise der Beispiele anhand von konkreten Zahlen genau klarmachen. 

• Wenn Sie noch keine Erfahrung im Umgang mit Modula haben, sollten Sie diese kurzen 
Anweisungsfolgen, die sich nicht auf der Diskette befinden, abtippen. Nehmen Sie dazu 
das dritte Eingangsbeispiel als »Rahmenprogramm«, laden es in den Editor und tauschen 
Sie die Variablenlisten und den Anweisungsteil aus! Die Importliste sowie die äußere 
REPEAT. . . UNTIL-Schleife zur wiederholten Durchführung kann bestehen bleiben. Die 
Ein- und Ausgabe muß den einzelnen Problemen angepaßt werden. Kompilieren Sie jedes 
Beispiel, und führen Sie es aus! 
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1.3.2 Der Datentyp LONGCARD 

Gelegentlich reicht der Zahlenbereich von CARDINAL nicht aus. Zum Beispiel entstehen in 
unserem Programmstück zur Potenz a b und zur Fakultät n! schnell Zahlen, die über 65535 
wachsen. Man geht dann zum Typ LONGCARD über, auf dem dieselben Operatoren ange¬ 
wandt werden können, der aber intern in 4 Byte = 32 Bit abgespeichert wird. Nach dem oben 
erklärten Prinzip ist also 

llllllllllllllllllllllllllllllll dual = 2 32 -1=4 2 9 4 9 6 7 2 9 5 

Das dürfte reichen, auch um die Kilometerleistung Ihres PKW abzuspeichern! 

Um die Euphorie etwas zu dämpfen, muß gesagt werden, daß man in einem Ausdruck - eben 
wegen der unterschiedlichen Maschinen-Darstellung - Variablen verschiedener Typen wie 
CARDINAL und LONGCARD nicht vermischen darf. 

Für c: CARDINAL; und lc: LONGCARD; ist der Ausdruck c+lc also nicht möglich. Wie auch? 
Von welchem Typ sollte das Ergebnis sein? Bei Zuweisungen lockern manche Compiler diese 
Kompatibilitätsforderung: sie gestatten die Zuweisung eines 2-Byte-Wertes auf einen 
4-Byte-Wert. Andersherum kann es Schwierigkeiten geben: eine 4-Byte-Zahl kann zu groß 
sein, als daß sie in einem 2-Byte-Wert dargestellt werden kann. 

Um zu verhindern, daß eine ungewollte Vermischung von 2-Byte-Typen und 4-Byte-Typen 
unerwartete Laufzeitfehler liefert, wird eine Anpassung der Datentypen mittels der zusätzli¬ 
chen Standardfunktionen SHORT und LONG erreicht. Somit sind folgende Zuweisungen er¬ 
laubt: 

c:=SHORT(lc) und lc:=LONG(c). 

Bei SPC-Modula ist eine Zuweisung in beiden Richtungen ohne Konvertierung möglich! 

Ein arithmetischer Ausdruck muß auch dann einen einheitlichen Typ haben, wenn man zum 
Beispiel mit CARDINAL und LONGCARD gleichzeitig arbeiten will. Man muß sich für einen Typ 
entscheiden; Variablen oder Teilausdrücke anderen Types müssen also mit Typtransfer- 
Funktionen umgewandelt werden. So erhält man entweder einen CARDINAL-Ausdruck 

c+SHORT ( 1 c ) oder einen LONGCARD- Ausdruck LONG ( c ) +1 c. 

Bei SPC sind SHORT und LONG aus SYSTEM zu importieren. 

Modula verlangt also bei allen Ausdrücken, daß die beteiligten Operanden vom gleichen (bzw. 
kompatiblen, s.u.) Typ sind! Diese Forderung »nervt« anfangs, wenn sie zuvor in Basic oder C 
gearbeitet haben. Man sollte jedoch bedenken, daß dadurch der Programmierer gezwungen 
wird, sich über den möglichen Wertebereich eines Ausdrucks beim Programmieren Klarheit 
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zu verschaffen. Der Ausdruck SHORT ( lc ) verhindert also keine Überläufe beim Programm¬ 
ablauf. 

Vorsicht ist geboten bei Ausdrücken, die den Wertebereich ihres Types überschreiten können; 
zum Beispiel führt folgende Sequenz zu einem Überlauf ( overflow ): 

VAR x,a: CARDINAL; 
a := 50000; 

x := a + 30000; (* 80000 ist mit CARDINAL nicht darstellbar!) 


Ebenso ist 


a := 300; 

x := a * a - 30000; (* müßte eigentlich 60000 ergeben *) 

fehlerhaft, da der Teilausdruck 300*300 bereits einen Überlauf beinhaltet (90000 ist halt 
nicht durch CARDINAL darstellbar), obwohl das Ergebnis nur 60000 ist. 

Allgemein gilt: Der Programmierer muß sicherstellen, daß alle Ausdrücke (auch Teilaus¬ 
drücke) zur Laufzeit keinen Überlauf oder Unterlauf ergeben. Ansonsten kann es zu einem 
Programmabbruch zur Laufzeit führen. Der Compiler kann das im allgemeinen nicht merken, 
da er nicht im voraus feststellen kann, welche Werte die Variablen zur Laufzeit annehmen 
werden. 

Zur Erläuterung des Umgangs mit L0NGCARD greifen wir das 5. Beispiel des vorigen Absatzes 
auf und schreiben ein vollständiges Programm: 

M0DULE FakultaetBerechnung; 

PROM InOut IMPORT ReadCard, WriteCard, WriteString, WriteLn, Read; 

VAR 

n, i : CARDINAL; 

fakultaet : LONGCARD; 
antwort : CHAR; 

BEGIN 

WriteString("Programm zur Berechnung von n!”); 

REPEAT 

WriteLn; WriteLn; 

REPEAT 

WriteString(”Geben Sie ’ n’ ein (0 <= n <= 12): ”); ReadCard(n); 
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IE n > 12 THEN WriteString(”Zu groß, Wiederholung»”); WriteLn END; 
UNTIL n < = 12; 
fakultaet:=1D; 

EOH i: =1 TO n DO fakultaet := fakultaet * LONG(i) END; 

WriteString(”Es gilt: ”); 

WriteCard(n,1); 

WriteString(”! = ”); WriteCard(fakultaet, 1); 

WriteLn; WriteLn; 

WriteString(”Wünschen Sie noch eine Berechnung (j/n)? ”); 

Read(antwort); 

antwort ;= CAP(antwort); (* Umwandlung in Großbuchstaben*) 

UNTIL antwort = ”N”; 

END EakultaetBerechnung. 


Sie können nun auch 12! = 479 001 600 (statt nur 8! =40320 bei der CARDINAL-Ver- 
sion) eingeben. Wenn man noch größere Zahlen braucht, geht man zum Datentyp REALüber. 

Das Programm zeigt einiges Neue: 

1. Damit keine Zahlen über 12 Vorkommen (13! >MAX (LONGCARD)), werden solche Ein¬ 
gaben in der REPEAT-Schleife zurückgewiesen. 

2. Zur Initialisierung braucht man die LONGCARD-Konstante Eins. Sie heißt »1D«(D: double 
precision =»doppelte Genauigkeit«). Bei Megamax ist auch »lL«erlaubt. 

3. LONG-CARD-Zahlen können mittels inOut. WriteCard ausgegeben werden. 


1.3.3 Die Datentypen INTEGER / LONGINT 

Diese beiden Typen repräsentieren ganze Zahlen. Der Unterschied zu CARDINAL besteht 
darin, daß auch negative Zahlen mit eingeschlossen sind. Eine INTEGER-Variable belegt 2 
Byte. Der Wertebereich von 65536 verschiedenen Werten (vergleiche Typ CARDINAL) verteilt 
sich auf den positiven und negativen Bereich: er beträgt deshalb -32768 bis 32767 (bei der 
positiven Hälfte wird ein Wert für die Null benutzt, darum ist sie um eins kleiner). Die positi¬ 
ven Zahlen (einschließlich Null) werden intern wie CARDINAL-Zahlen gespeichert; das höchst¬ 
wertige Bit (das mit der Nummer 15, also das ganz linke) ist dabei Null. Beträgt es Eins, so 
handelt es sich um eine negative Zahl. 
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Die 32768 Zahlen von 0 bis 32767 haben die Darstellung 

Oxxxxxxxxxxxxxxx, beispielsweise 

oooooooooooooooi entspricht 1 und 

Olllllllllllllll entspricht 32767. 

Die 32768 negativen Zahlen von -32768 bis -1 haben die Darstellung 

lxxxxxxxxxxxxxxx, beispielsweise 

llllllllllllllll entspricht -1 und 

1000000000000000 entspricht -32768. 

Analog dazu existiert ein Typ LONGINT, in dem ganze Zahlen in 4 Byte abgespeichert werden. 
Er umfaßt daher den Wertebereich von -2147483648 (=-2 31 ) bis 2147483647 (= 2 31 -1) 

Auf INTEGER / LONGINT-Variablen sind die gleichen Operatoren wie auf CARDINAL-Variab- 
len erklärt. Das gilt auch im großen und ganzen für die Standardfunktionen (vergleiche dort). 

INTEGER- und LONGINT-Variablen dürfen in einem Ausdruck nicht miteinander vermischt 
werden; SPC-Modula erlaubt allerdings ihre gegenseitige Zuweisung. Bei Megamax-Modula 
sind die Typtransfer-Funktionen LONG und SHORT zu verwenden. 

Ebensowenig ist es erlaubt, in einem Ausdruck INTEGER- und CARDINAL-Typen zu mischen. 
Das leuchtet ein, wenn man die besondere interne Darstellung der negativen Zahlen berück¬ 
sichtigt. Nach der Deklaration 

YAR 

cl, c2: CARDINAL; 
il, 12: INTEGER; 

sind folgende Anweisungen nicht erlaubt: 

c2 := cl + il; 
i2 := il DIV cl; 

Hier besteht die Notwendigkeit, einen der beiden Typen INTEGER und CARDINAL innerhalb 
des Ausdruckes in den anderen umzuwandeln. Man kann sehr einfach Ausdrücke in einen an¬ 
deren Typ umwandeln, indem man den Typ, den der Ausdruck erhalten soll, wie eine Funk¬ 
tion davor schreibt: 

c2 := cl + CARDINAL(i1); 
i2 := il DIV INTEGER(cl); 

Ein solcher »Typtransfer« läßt sich auch für alle anderen Typen verallgemeinern: 


<NeuerTyp>{<Ausdruck >) 
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Der Ausdruck erhält damit den Typ <NeuerTyp>. 

Allgemein läßt sich jeder Ausdruck mit so einem Typtransfer in einen anderen Typ 
verwandeln. 

Modula erlaubt es jedoch, INTEGER-Ausdrücke CARDINAL-Variablen zuzuweisen und umge¬ 
kehrt; man sagt, INTEGER und CARDINAL sind untereinander »zuweisungskompatible« Da¬ 
tentypen. Das gleiche gilt für LONGINT / LONGCARD. Zur Verdeutlichung folgendes Beispiel: 
nach der Deklaration 

VAR 

c: CARDINAL; lc: LONGCARD; 
i: INTEGER; li: LONGINT; 

sind folgende Zuweisungen korrekt: 

i : = c; 
lc := li; 

Es bleibt noch zu sagen, daß man INTEGER / LONGINT-Variablen nur dann einsetzen sollte, 
wenn ausdrücklich negative Werte Vorkommen. Ansonsten ist CARDINAL / LONGCARD vor¬ 
zuziehen. 

Ganzzahlen-Arithmetik läuft deutlich schneller als REAL-Arithmetik (real: gebrochene 
Zahlen, siehe nächster Abschnitt). Viele Problemstellungen, deren Lösungen auf den ersten 
Blick REAL-Arithmetik verlangt, kann man mit Ganzzahlen bearbeiten. Hier ein Beispiel: 

Vielleicht haben Sie sich schon gefragt, wie ein Computer Kreise zeichnet. Hierzu müssen die 
Koordinaten eines jeden Kreispunktes errechnet und dann gezeichnet werden. Man denkt bei 
der Berechnung unwillkürlich an Pythagoras; die Kreisgleichung für einen Kreis mit Mittel¬ 
punkt (0,0) 

x 2 +y 2 = r 2 

kann man nach y auflösen. Dazu braucht man aber die Wurzelfunktion, die selbstverständ¬ 
lich für ganze Zahlen nicht definiert ist (für REAL- Variablen gibt es natürlich eine...). Eine An¬ 
dere Möglichkeit wäre der Einsatz von Sinus- und Kosinus-Funktion: 

x=r*cos (oc) 

und 

y=r*sin(a) 

aber hier kommt man erst recht nicht mit ganzen Zahlen aus. 

Da die Bildschirmkoordinaten, an denen die Kreispunkte gezeichnet werden, ganzzahlig sind, 
müßten wir die berechneten reellen Zahlen ohnehin wieder auf ganze Zahlen runden. Versu¬ 
chen wir also doch lieber direkt eine Ganzzahlen-Lösung: 
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Zunächst kann man, wenn man einen Kreis¬ 
punkt k = (x, y) errechnet hat, wegen der 
eingezeichneten Symmetrieachsen sieben 
weitere Punkte (y,x), (y, -x), (x, -y), 
(-x,-y), (-y> -x), (-y,x), (-x,y) 

einzeichnen. Das heißt, man braucht nur die 
Punkte des Achtelkreises von A bis B zu er¬ 
mitteln. Den Punkt A kennt man: A = (0, r), 
wenn r der Radius des Kreises ist. 

Hat man aber einen Punkt (x,y) auf dem 
Kreisbogen (AB), kann man den im Uhrzei¬ 
gersinn nächsten nach folgendem Algorithmus 
(Bresenham 1977) ermitteln: 

In Frage kommt nur der Bildschirmpunkt 
P(x+l, y) (rechts daneben) oder Q(x+1, y-l) 
(rechts unterhalb). Je nachdem, welcher Punkt 
vom nächsten wirklichen Kreispunkt weniger 

Das Quadrat der Entfernung OP beträgt: 

|0P| 2 = (x+1) 2 +y 2 
also ist 

dP=(x+1) 2 +y 2 -r 2 

ein Maß für die Abweichung des Punktes P 
vom Kreisrand. Es gilt: dP^O, da P im Nor¬ 
malfall außerhalb des Kreises liegt, im Ideal¬ 
fall auf dem Kreis. 

Analog ist 

dQ=r 2 -((x+1) 2 + (y-l) 2 -r 2 ) 

ein Maß für die Abweichung des Punktes Q 
vom Kreisrand. Es gilt: dQ^O. 

Die Entscheidungsregel lautet also: 

ist dP>dQ, so wähle Q als nächsten Punkt, 
sonst P. 



Bild 1.9: Die Achtpunkte- 
Symmetrie eines Kreises 

weit entfernt ist, wählt man P oder Q. 



Bild 1.10: Mögl. Nachbar¬ 
punkte zum Kreispunkt A 
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Wir formen noch etwas um: 
dP>dQ 

<=> dP—dQ>0 

< = > 2((x+1) 2 +y 2 -y-r 2 )+1>0 

< = > (x+1) 2 +y 2 -y-r 2 >-0.5 

Da hier nur ganze Zahlen Vorkommen, ist diese Ungleichung äquivalent zu der Beziehung: 
(x+1) 2 +y 2 -y-r 2 ^0 

In Modula ausgedrückt sieht der Übergang vom Punkt 
(x, y) nach (x+1, y) oder (x+1, y-1) dann so aus: 

INC(x); 

IF x*x + y*y - y - r*r >= 0 THEN DEC(y) END; 

Das war schon alles! 

Der Ausdruck r*r ist konstant, deshalb berechnen wir ihn vor der Schleife 
rHoch2: =r*r. 

Dies ist ein allgemeines Prinzip zur Geschwindigkeitsoptimierung: Die Wiederholung von 
identischen Ausdrücken in einer Schleife sollte vermieden werden! 

Da noch keine Grafik eingeführt ist (kommt in Kapitel 4) benutzen wir zu Testzwecken den 
Textbildschirm. Die Positionierung des Cursors an die Spalte x und die Zeile y erreicht man 
mit GotoXY(x, y )aus dem Modul Terminal. Da wir einen Textbildschirm mit 80 Spalten zu 
je 25 Zeilen haben, gilt 

0^x^79 und 0^y^24. 

Für jeden Punkt malen wir einen Stern »*«. Der Kreis wird stark in der Vertikalen gestreckt, 
da auf dem Textbildschirm die Zeichenhöhe größer als die Breite ist. 

Falls Sie ein anderes System als Megamax oder MSM2 benutzen, ist die Prozedur GotoXY 
nicht im Modul Terminal oder inOut enthalten, da dies nicht von N. Wirth vorgesehen 
wurde. Schreiben Sie sich einfach selber eine Prozedur GotoXY! Man fügt dazu nach der 
Variablendeklaration (vor dem BEGIN also) folgendes ein: 

PROCEDURE GotoXY(x,y:INTEGER); 

BEGIN 

Write(33C); Write(”Y”); Write(CHR(32+x)); Write(CHR(32+y)) 

END GotoXY; 
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Was hier im einzelnen passiert, bleibt vorerst noch geheimnisvoll, wird aber in späteren Ab¬ 
schnitten erklärt. Kompilieren Sie das komplette Programm selbst und lassen Sie es laufen. 

MODULE Kreis; (* Kreisdarstellung nach BRESENHAM 1977 *) 

EROM Terminal IMPORT Read, Write, GotoXY; 

VAR 

x, y, xMitte, yMitte, r, rHoch2 : INTEGER; 
taste : CHAR; 

BEGIN 

xMitte := 40; yMitte := 12; r : = 8; 
x := 0; y := r; rHoch2 : = r * r; 

REPEAT 

GotoXY(xMitte+x, yMitte+y); Write(”*”); 

GotoXY(xMitte+y, yMitte+x); Write(”*”); 

GotoXY(xMitte+y, yMitte-x); Write(”*”); 

GotoXY(xMitte+x, yMitte-y); Write(*****); 

GotoXY(xMitte-x, yMitte-y); Write(”*”); 

GotoXY(xMitte-y, yMitte-x); Write(”*”); 

GotoXY(xMitte-y, yMitte+x); Write(”*”); 

GotoXY(xMitte-x, yMitte+y); Write(”*”); 

INC(x); 

IF x*x + y*y - y - rHoch2 >= 0 THEN DEC(y) END 
UNTIL x >= y; 

GotoXY(l,20); Read(taste) 

END Kreis. 


Das Programm endet mit Read(taste). Dort wartet der Rechner auf einen beliebigen 
Tastendruck. Das hat nur den Sinn, daß das Programm an der Stelle nicht sofort beendet 
wird und das Ergebnis auf dem Bildschirm sichtbar bleibt. Manche Modula-Systeme räumen 
nämlich nach Beendigung eines Programms sofort den Bildschirm auf, ohne daß man 
Gelegenheit hat, sich die Ausgaben des Programmes anzusehen. 

Selbstverständlich existieren für das Zeichnen eines Kreises fertige Grafik-Routinen in der 
GEM-Bibliothek (vgl. Kapitel 4). Aber es empfiehlt sich dennoch zu wissen, wie so etwas ge¬ 
macht wird. Auch das Zeichnen von Linien mit beliebiger »reeller« Steigung führt man auf 
Ganzzahl-Arithmetik zurück. Bildpunkt-Koordinaten sind eben nur ganze Zahlen. 
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1.3.4 Die Datentypen REAL / LONGREAL 

Diese Datentypen repräsentieren eine Teilmenge der gebrochenen Zahlen. Wir sprechen hier 
absichtlich nicht von reellen Zahlen, da irrationale Zahlen wegen ihrer unendlichen Anzahl 
von Nachkommastellen nicht von einer Maschine dargestellt werden können. 

RE AL-Variablen werden bei Hänisch-, SPC- und TDI-Modula mit 4 Byte dargestellt. Daneben 
gibt es den Typ LONGREAL, er umfaßt 8 Byte. In Megamax-Modula haben REAL-Variablen di¬ 
rekt 8 Byte, den Typ LONGREAL gibt es hier nicht. Viele Compiler (SPC, TDI) speichern 
REAL-Variablen in einem genormten Format, dem »IEEE-Single-Precision-Format«: 

Speicherbedarf: 4 Byte 

Wertebereich: -3.3 * 10 38 bis 3.3 *10 38 

Ebenso wird dort für LONGREAL mit 8-Byte das IEEE-Double-Precision-Format verwendet: 

Speicherbedarf: 8 Byte 

Wertebereich: -1.79 *10- 3 ° 8 bis 1.79 *10 308 

Megamax benutzt ein eigenes Format, das eine schnellere Arithmetik erlaubt. Hier reicht der 
Wertebereich für die 8 Byte-Real bis 10 1233 . 

Alle diese Wertebereiche sollten also ausreichen, um auch größere Zahlen zu bearbeiten, wie 
sie zum Beispiel bei der Führung Ihres Girokontos Vorkommen! 

Das Abspeichern von RE AL-V ariablen ist wesentlich komplizierter als bei den Ganzzahl-V aria- 
blen und variiert auch zwischen den verschiedenen Formaten. Allen Formaten ist aber folgen¬ 
des gemeinsam: 

• Es wird der Exponent der Zahl zur Basis 2 gespeichert. 

• Die eigentliche Ziffernfolge der Zahl, die Mantisse , wird auch im Dualsystem dargestellt. 

• Man richtet den Exponenten beim Abspeichern so ein, daß die Mantisse 

0, lxx. . . xx lautet. Dies ist für alle Zahlen außer Null möglich; Null wird gesondert ge¬ 
kennzeichnet. 

• Außerdem müssen noch das Vorzeichen der Mantisse und des Exponenten verwaltet 
werden. 

All das braucht Sie als Modula-Programmierer nicht zu kümmern, der Computer erledigt es 
für Sie. Wir erwähnen es nur, um ein gewisses »Problembewußtsein« zu schaffen: Es ist klar, 
daß eine REAL-Arithmetik wesentlich langsamer als eine Ganzzahl-Arithmetik abläuft. Daher 
sollte man Ganzzahlen (CARDINAL, INTEGER; auch L0NGCARD oder L0NGINT) nutzen, wenn 
nicht unbedingt gebrochene oder sehr große Zahlen benötigt werden. Außerdem können we- 
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gen der endlichen Stellenzahl bei Real-Variablen in Berechnungen Rundungsfehler auftreten; 
bei Ganzzahl-Arithmetik kommt so etwas nicht vor. 

Nach diesen Vorbemerkungen einige Beispielprogramme, die das Arbeiten mit gebrochenen 
Zahlen zeigen. Hierzu ist noch zu sagen, daß auf REAL-Variablen die gleichen Operatoren wie 
auf CARDINAL- und INTEGER-Variablen anwendbar sind mit der Ausnahme von MODund DI V. 
Statt dessen gibt es das Divisions-Zeichen »/«. Der Ausdruck 5. 0/2. 0 ergibt 2.5. 

MODULE Kugel; 

FROM InOut IMPORT ReadReal, WriteReal, Read, WriteString, WriteLn; 

CONST Pi = 3.141592654; 

VAR r, Volumen, Oberflaeche : REAL; 

BEGIN 

WriteString(”Berechnung des Kugelvolumens und der Oberfläche”); 

WriteLn; 

REPEAT 

WriteLn; WriteString(”Geben Sie den Radius in Metern ein (0 = Ende): ”); 
ReadReal(r); WriteLn; 

Volumen := 4.0 / 3.0 * Pi * r * r * r; 

Oberflaeche : = 4.0 * Pi * r * r; 

WriteString(”Das Kugelvolumen beträgt: ”); 

WriteReal(Volumen,1,3); WriteString(” Kubikmeter,”); WriteLn; 

WriteString(”Die Oberfläche beträgt: ”); 

WriteReal(Oberflaeche,1,2); WriteString(” Quadratmeter.”); WriteLn; 

UNTIL r = 0.0 
END Kugel. 


Wenn Ihr Compiler die Prozeduren WriteReal und ReadReal nicht im Modul InOut fin¬ 
det, so werden sie im Modul ReallnOut bereitgestellt. Die Importliste muß dann heißen: 

FROM ReallnOut IMPORT ReadReal, WriteReal; 

FROM InOut IMPORT Read, WriteString, WriteLn; 

Was ist neu an diesem Programm? 

Zunächst haben wir einmal eine Konstanten-Deklaration, die mit CONST eingeleitet wird. 
Dem Bezeichner Pi wird der REAL-Wert 3.141592654 zugeordnet. Sinn einer Konstanten¬ 
deklaration ist, daß der Compiler überall dort, wo im Quelltext das Symbol Pi auftritt, dieses 
Symbol durch 3.141592654 ersetzt. 
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Gehen wir noch kurz auf die Berechnung des V olumens ein. In der F ormelsammlung Finden sie 
für das Kugelvolumen V die Formel 

V = 4/3 7i r 3 

In Modula gibt es aber keinen Potenzoperator für »Hoch«, daher multiplizieren wir den Ra¬ 
dius dreimal. Man darf aber nicht einfach 

volumen := 4/3 *Pi*r*r*r;(*falsch!*) 

programmieren, da 4 und 3 als integer- oder CARDINAL-Konstanten erkannt werden. Eine 
REAL-Konstante muß unbedingt einen Dezimalpunkt». « enthalten. Also 4. 0 statt 4, anson¬ 
sten meldet der Compiler einen Typ-Konflikt, da 

1. der Operator / nicht auf Ganzzahlen anwendbar ist und 

2. keine Ganzzahlen und REAL-Variablen in einem Ausdruck vermischt werden dürfen. 

Im nächsten Beispiel sollen beliebig viele reelle Zahlen eingelesen werden. Es erfolgt als Aus¬ 
gabe der Summe des Maximums und Minimums des Mittelwertes. Um letzteren zu errechnen, 
müssen wir die Eingaben zählen. Hierzu nimmt man selbstverständlich eine CARDINAL-Varia- 
ble; wir nennen sie anzahl. Der Mittelwert berechnet sich bekanntlich als Quotient aus 
Summe durch Anzahl.Wir können aber nicht einfach schreiben: 

Mittelwert := summe / anzahl; (»falsch!*) 

da wir dabei einen REAL-Ausdruck durch einen CARDINAL-Ausdruck dividieren würden. Des¬ 
halb muß man anzahl nach REAL konvertieren. Das geschieht mittels der Funktion FLOAT: 

Mittelwert := summe / FLOAT(anzahl); 

Das ganze Programm sieht dann folgendermaßen aus: 

MODULE MittelWertBerechnung; 

FROM InOut IMPORT ReadReal, WriteReal, Read, Write, 

WriteCard, WriteString, WriteLn; 

VAR 

zahl, summe, Min, Max, Mittelwert 
anzahl 
taste 

BEGIN 

WriteString(”Mittelwertberechnung”); WriteLn; WriteLn; 

WriteString(”Geben Sie fortlaufend Zahlen ein, Beenden mit 0 !”); 


: REAL; 

: CARDINAL; 
: CHAR; 
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WriteLn; WriteLn; 

summe := 0.0; Min := MAX(REAL); Max := MIN(REAL); 
anzahl := 0; 

REPEAT 

WriteString(”Zahl: ”); ReadReal(zahl); WriteLn; 

IE zahl #0.0 THEN 
INC(anzahl); 
summe := summe + zahl; 

IE zahl > Max THEN Max := zahl END; 

IE zahl < Min THEN Min := zahl END; 

END 

UNTIL zahl = 0.0; 

Mittelwert := summe / ELOAT(anzahl); 

WriteString(”Sie gaben insgesamt ”); 

WriteCard(anzahl,1); WriteString(” Zahlen ein.”); WriteLn; 

WriteString(”Die Summe beträgt ”); 

WriteReal(summe,1,4); Write(”.”); WriteLn; 

WriteString(”Der Mittelwert beträgt ”); 

WriteReal(Mittelwert,1,4); Write(”.”); WriteLn; 

WriteString(”Das Maximum beträgt ”); 

WriteReal(Max,1,4); Write(”.”); WriteLn; 

WriteString(”Das Minimum beträgt ”); 

WriteReal(Min,1,4); Write(”.”); WriteLn; 

WriteLn; WriteString("Bitte Taste drücken! ”); 

Read(taste) 

END MittelWertBerechnung. 

Die drei folgenden Beispiele sollen Sie ein wenig mit der Problematik von Rundungsfehlern 
vertraut machen. 

Wenn x = l. 0 ist, so ist 1. 0 + x sicherlich größer als l. 0. Das stimmt auch noch, wenn 
man x fortlaufend halbiert. Also dürfte die WHILE-Schleife im folgenden Programm nicht 
abbrechen: 

M0DULE RundungsDemol; 

FR0M InOut IMPORT WriteReal, Read; 

VAR 

x : REAL; 

taste : CHAR; 
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BEGIN 

x := 1.0; 

WHILE 1.0 + x > 1.0 DO x := x/2.0 END; 
WriteReal(x,20,18); 

Read(taste) 

END RundungsDemol. 


Tatsächlich erfolgt aber ein Abbruch, es wird beim Megamax-Compiler 
1. 7763568394002E-15 ausgegeben (das bedeutet ca. 1.776 *10 -15 , also eine sehr kleine 
Zahl). Wie kommt es dazu? Offensichtlich bleibt eine Addition von Zahlen mit zu starken 
Größenunterschieden wirkungslos! Unterschreitet x eine bestimmte Größe, so wird 

1.0 + x = 1.OOOOOOOOOOOOOOxxxxxx 

und die weiteren Stellen werden wegen der endlichen Stellenzahl des Rechners abgeschnitten; 
für den Rechner ist die Zahl gleich l. 0. 

Aus dem gleichem Grunde sollte man Abbruchsbedingung für Schleifen in der Form 

REPEAT <...> UNTIL x = y; oder 
WHILE x = y DO <. . . > END; 

mit VAR x, y: REAL vermeiden, da sich x und y um einen zu kleinen Betrag voneinander 
unterscheiden können. Statt dessen sollte man Abbruchsbedingungen der Form 

ABS (x - y) < 1. OE- 10 oder x <= y bzw. x >= y 

verwenden. Hierzu als Beispiel: 

x : = 0.1; 
summe : = 0.0 
REPEAT 

summe := summe + x 
UNTIL summe = 10.0 

Diese Schleife sollte eigentlich nach 100 Additionen abbrechen. Tut sie aber nicht! Denn intern 
kann der Rechner 0. l nicht »glatt« als Dualzahl darstellen; dadurch wird die lOOmalige 
Addition nicht genau 10. 

Das folgende Programm terminiert nur nach Tastendruck; hierzu benutzen wir die Prozedur 
KeyPressedaus dem Modul inOut, die TRUE liefert, wenn man eine Taste drückt. Wenn Ihr 
System KeyPressed nicht bereitstellt, schreiben Sie es sich selbst: 
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PROCEDURE KeyPressed: BOOLEAN; 
VAR taste: CHAR; 

BEGIN 

BusyRead(taste); 

RETURN taste # OC 
END KeyPressed; 


Fügen sie diese Zeilen vor dem BEGIN ein. Die Importliste lautet nun: 

PROM InOut IMPORT WriteReal; 

PROM Terminal IMPORT BusyRead; 

MODULE RundungsDemo2; 

PROM InOut IMPORT WriteReal, KeyPressed, WriteString, Read; 

VAR x, summe : REAL; 

Taste : CHAR; 

BEGIN 

x : = 0.1; 
summe : = 0.0; 

WriteString(”Bitte nach einiger Zeit eine Taste drücken! ”); 
REPEAT 

summe : = summe + x; 

UNTIL (summe = 10.0) OR KeyPressed(); 

WriteReal(summe, 15,13); 

WHILE KeyPressed() DO Read(taste) END; Read(taste) 

END RundungsDemo2. 


Lassen Sie das Programm einige Sekunden laufen, drücken sie dann eine Taste. Sie werden sich 
wundern, wie groß summe inzwischen geworden ist. 

Wenn sie das Gleichheitszeichen in der Abbruchsbedingung durch »>=« ersetzen, funktioniert 
alles ordnungsgemäß. Ausprobieren! 

Es kommt noch toller! 

Vielleicht haben Sie einen guten Mathematikunterricht genossen und können sich noch dun¬ 
kel daran erinnern, daß für den Kreisumfang U bei einem Radius r. U = 2 kt gilt, »tu« ist dem¬ 
nach der halbe Umfang eines Einheitskreises (Radius = 1). Um diesen Wert zu ermitteln, 
zeichnet man seit Avchimedes (287-212 v.Chr.) regelmäßige Vielecke in einen Kreis und be¬ 
rechnet deren Umfang. Beginnt man mit einem Dreieck, so hat es die Seitenlänge 
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s 3 = |AB| = y/3~ 

Es sei x = ME. 

Aus dem Dreieck DCA folgt: 
s 6 2 = 2 (1-x) (Höhensatz, DC=2, MC=1) 

Aus dem Dreieck MEA folgt wegen MA= 1: 
x 2 = 1 -(s 3 /2) 2 
Also ist_ 

s 6 = n/2-V 4 " s 3 2 

Wir haben bei der Herleitung keinen Gebrauch 
von der speziellen Eckenzahl 3 bzw. 6 gemacht. 

Also gilt allgemein bei der Eckenzahl eines ein¬ 
beschriebenen n-Ecks: 

S2n=V2- N / 4 - s n 2 

Die Wurzelfunktion sqrt importiert man wie 
alle anderen wichtigen Funktionen für REAL- 
Variablen aus dem Modul MathLibO oder 
MathLib, je nach System. 

MODULE PiNachArchimedes; 

PROM InOut IMPORT WriteReal, WriteCard, WriteString, WriteLn, Read, 
RedirectOutput, CloseOutput; 

PROM MathLibO IMPORT sqrt; 

VAR 

s 

n, ende 
taste 

BEGIN 
n : = 3; 
s: = sqrt(3.0); 

ende := MAX(LONGCARD) DIV 2D; 

Writeln; WriteString("Ausgabe auf Drucker (j/n)? ”); Read(taste); 

IP CAP(taste) = ”J” THEN RedirectOutput(PRN:”, PALSE) END; 

WriteString(Berechnung von Pi”); 

WriteLn; WriteLn; 

WHILE n < ende DO (* aufhören, sonst Überlauf bei der Mult, mit 2 *) 

n : = n * 2D; 

s := sqrt( 2.0 - sqrt( 4.0 - s*s )); 

WriteString(”Eckenzahl: ”); WriteCard(n, 10); 


REAL; 

LONGCARD; 

CHAR; 



Bild 1.11: Zur Herleitung der Formel 
»Pi nach Archimedes« 
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WriteString(”, Näherungswert für Pi: ”); 

WriteReal(s * PLOAT(n DIV 2D),15,13); WriteLn 
END; 

IP CAP(taste) = 99 J" THEN CloseOutput END; (* Drucker-Ausgabe beenden *) 

Writeln; WriteString(’ , Taste drücken! ”); Read(taste); 

END PiNachArchimedes. 


Die Prozedur RedirectOutput aus InOut bewirkt die Umleitung der Ausgabe. Wir wollen 
den Drucker (»PRN: «) als Ausgabegerät ansprechen. 

Zunächst sieht alles ganz gut aus, die Werte nähern sich rc( = 3, 141592 653 589 793. . . ) 
Bei der Eckenzahl 12288 wird der Wert 3,14159265332. . . erreicht. Aber dann wird es 
drastisch schlechter, am Ende sogar =0 ! Das sollte man ausprobieren. 

An der Formel 

s 2n = x/^T^T 

erkennt man, daß bei sehr hoher Eckenzahl n der Wert s£ so klein werden kann, daß der 
Computer 4-s^ zu 4 rundet, woraus sich für s 2n = 0 ergibt. Man spricht hier von einer 
»Subtraktions-Katastrophe«. Die Differenz zweier sehr nahe beieinander liegenden Zahlen 
kann der Computer nicht mehr von Null unterscheiden! Wie läßt sich so etwas vermeiden? 

Man macht folgende geschickte mathematische Umformung. Der Term 

s 2n = wird mit +y/4-s£ erweitert. 

Es ergibt sich 

S 2 n= S„/n/ 2 + \/4 - S n 2 

Hier tritt keine Subtraktionskatastrophe ein. Ändert man das Programm entsprechend ab, so 
erhält man (Megamax, 8-Byte-REAL’s): 

Eckenzahl:3221225472, Näherungswert für Pi: 3.1415926535899 

Ein entsprechend abgeändertes Programm befindet sich auf der Diskette. 

Diese Beispiele sollten Sie kritisch für den allzu sorglosen Umgang mit real- Variablen ma¬ 
chen. Es sei betont, daß Rundungsfehler systemimmanent sind. Sie sind begründet in der 
computerspezifischen Darstellung von reellen Zahlen. Es handelt sich also nicht etwa um eine 
Unzulänglichkeit von Modula! 

Neben der Subtraktion ist auch die Division nicht unproblematisch. Dividiert man durch eine 
Zahl, die sehr nahe bei Null liegt, kann es zu Überläufen kommen. 
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Das letzte Demoprogramm zu REAL’s ist eher als »Gag« gedacht. Es zeigt eine näherungs¬ 
weise Bestimmung von n mittels eines Zufallsgenerators. 

Stellen Sie sich ein Quadrat von 1 m Kanten¬ 
länge vor, in das ein Viertelkreis (Radius 1 m) 
eingezeichnet ist. Nun regnet es, und die Vier- 
telkreisfläche wie auch das gesamte Quadrat 
wird gleichmäßig naß. Wir zählen die Gesamt¬ 
zahl der Regentropfen t und die Zahl derjeni¬ 
gen Tropfen k, die in den Viertelkreis fallen. 

Der Quotient k/t ist dann ein Maß für die Flä¬ 
che des Viertelkreises. Sein Vierfaches also ein 
Näherungswert für n. 

Einen Regentropfen mit den Koordinaten 
(x,y) mit 0 ^ x ^ 1 und 0 ^ y ^ 1 erzeugt 
man mit einem Zufallsgenerator. Hierzu bietet 
Megamax-Modula die Prozedur Random aus 
dem Modul RandomGen an. 

MODULE PiDurchZufallsRegen; 

FROM InOut IMPORT Read, WriteReal, WriteCard, WriteString, 

WriteLn, KeyPressed; 

FROM RandomGen IMPORT Randomize, Random; 

VAR 

Tropfen, KreisTropfen : LONGCARD; 
x, y : REAL; 

Taste : CHAR; 

BEGIN 

Tropfen :=0D; 

Randomize(OD); (* Zufallsgenerator mit zufälligem Wert initialisieren *) 

WHILE ( Tropfen < MAX(LONGCARD) ) AND NOT KeyPressed() DO 
INC(Tropfen); 
x := Random(); 
y := Random(); 

IF x*x + y*y <1.0 THEN INC(KreisTropfen) END 

END; 

WriteString(”Insgesamt regnete es ”); WriteCard(Tropfen, 1); 

WriteString(” Tropfen,”); WriteLn; 

WriteString(”davon trafen ”); WriteCard(KreisTropfen, 1); 

WriteString(” den Viertelkreis.”); WriteLn; 



Bild 1.12: »Pi durch Zufallsregen« 
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WriteString(”Der Näherungswert für Pi durch Zufallsregen beträgt also ”); 
WriteReal(4.0 * FLOAT(KreisTropfen) / FLOAT(Tropfen),15,13); 

Read(Taste); Read(Taste) 

END PiDurchZufallsRegen. 


Ob ein Tropfen in den Viertelkreis gefallen ist, wird mit seinem Abstand 
d = s Jx 2 + y 2 

zum Nullpunkt überprüft. Ist d < 1, so liegt der Tropfen im Kreis. Dies ist hier gleichbedeutend 
mit (x 2 +y 2 ) < 1. 

Zum vorläufigem Abschluß der Arbeit mit REAL-Zahlen fassen wir zusammen: 

1. In einem Ausdruck dürfen nicht REAL- mit INTEGER- oder CARDINAL-Variablen gemischt 
Vorkommen. Man muß vorher konvertieren und benutzt dazu die Transferfunktionen 
FL0AT (bei einigen Compilern für Langzahlen FLOATD), 

TRUNC (bei einigen Compilern für Langzahlen TRUNCD) 

2. Weitere Standardfunktionen für REAL sind: 

ABS (Absolutbetrag), min und MAX. 

Achtung: DEC und INC arbeiten nicht mit REAL! 

Im übrigen gibt es noch einige Funktionen im Modul MathLibO oder MathLib, unter 
anderem trigonometrische Funktionen. 

3. Die Ein- und Ausgabe von REAL-Werten erfolgt mit ReadReal und WriteReal aus dem 
Modul inOut; bei manchen Systemen stehen diese Funktionen allerdings in einem extra 
Modul Real InOut. Bei der Eingabe über diese Funktionen kann der Dezimalpunkt ent¬ 
fallen. 

4. REAL-Konstanten sind mit Dezimalpunkt zu schreiben: also 3. 0 statt 3. Sehr große und 
sehr kleine Zahlen schreibt man mit Exponent: z.B. 3. OEll, -4.8E-14 (bedeutet 
3*10 n bzw. -4. 8*10- 14 ). 

1.3.5 Der Datentyp BOOLEAN 

Dieser Datentyp (benannt nach dem Mathematiker Georges Boole) repräsentiert die Wahr¬ 
heitswerte FALSE (falsch) und TRUE (wahr). Als Anwendungsgebiet von B00LEAN- 
Variablen ist das Steuern von Schleifen und bedingten Anweisungen zu nennen. Boolesche 
Ausdrücke haben Sie bereits in einer Schleife kennengelernt: 


REPEAT <. . . > UNTIL x=y; 
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Hier stellt »x = y« einen Booleschen Ausdruck dar. Das Ergebnis eines solchen Vergleichs 
läßt sich einer Variablen vom Typ BOOLEAN zuweisen! Wie, sehen Sie in diesem Abschnitt. 

Rechnerintern wird eine BOOLEAN-Variable in einem Byte (Hänisch-, SPC- und TDI-Modula) 
oder zwei Byte (MSM2, Megamax-Modula) dargestellt: 

EALSE entspricht dem Bitmuster 00000000 und 
TRUE entspricht dem Bitmuster 00000001. 

Wie sie sehen, wird die entscheidende Information nur in einem einzigem Bit dargestellt. Mehr 
ist eigentlich nicht nötig! 

Folgende Operatoren sind auf BOOLEAN-Variablen anwendbar: 

1. Zweistellige Operatoren: 

AND: p AND q oder p & q: p und q sind wahr 

OR: p OR q: p oder q (oder beide) sind wahr 

2. Einstellige Operatoren: 

NOT: NOT p oder ~p: nicht p (p ist falsch) 

3. Vergleichs-Operatoren (Relationen): 

<,>,<=,>=, = ,# (oder<>) 

es gilt: FALSE < TRUE (siehe oben interne Darstellung!) 

Ähnlich wie bei Zahlen, bei denen das Vorzeichen am stärksten bindet, danach * und /(bzw. 
DIV, MOD) Vorrang hat vor + und gibt es auch für die obigen Operatoren Vorrangregeln in 
Ausdrücken: NOT hat den höchsten Rang, es folgt AND (»logische Multiplikation«), dann OR 
(»logische Addition«). Den geringsten Rang haben die Relationen. 

Relationen liefern immer ein Ergebnis vom Typ BOOLEAN. Die Argumente können aber außer 
vom Typ BOOLEAN noch von den folgenden Typen sein: INTEGER / LONGINT, CARDINAL / 
LONGCARD, REAL / LONGREAL, CHAR, Aufzählungs- und Unterbereichstypen und teilweise 
Mengen (BITSET, SET OF. . .). Die beiden Argumente müssen natürlich von demselben Typ 
sein: 

7 < 12 TRUE 

7 = 12 FALSE 

7.2# 12. 0 TRUE 

Wegen des geringen Vorranges der Relationen nach AND und ORmuß man für »falls a<b oder 
c# d dann...« in Modula Klammern benutzen: 


IF (a < b) OR (c # d) THEN <...> END; 
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Wichtig: die Auswertung eines Booleschen Ausdruckes wird abgebrochen, sobald sein Ergeb¬ 
nis fest steht. Im Klartext: p AND q ist auf jeden Fall falsch, falls p bereits FALSE ist. Der 
Wahrheitswert von q wird in diesem Fall nicht mehr geprüft! Daher erzeugt die Abfrage 

IP (a # 0) AND (b DIV a < 10) THEN <...> END; 

keinen Fehler »Divison durch 0«, falls a=0 ist! Vertauscht man die Argumente von AND: 

IP (b DIV a < 10) AND (a # 0) THEN ... END; 
so tritt für a=0 sofort der Fehler auf. 

p 0R q ist auf jeden Fall wahr, falls p bereits TRUE ist, und q wird dann nicht mehr geprüft. 
Dies sollte man beachten, wenn auf eine hohe Ablaufgeschwindigkeit Wert gelegt wird. 

Weiter Tips: 

1. Der Ausdruck 

IP p = TRUE THEN <. . . > END; 
ist unsinnig, denn es reicht ja 
IP p THEN <. . . > END; 

Folgende Konstruktion findet man selbst in Profi-Programmen: 

IP p = TRUE THEN q := PALSE 
ELSE q := TRUE 

END; 

Was natürlich viel übersichtlicher gelöst wird mit: 
q := NOT p; 

2. Es gelten die DE MORGAN’schen Gesetze: 

(NOT p) AND (NOT q) = NOT (p 0R q) 

(NOT p) 0R (NOT q) = NOT (p 0R q) 

3. Die logische Antivalenz (»entweder p oder q«, in manchen Sprachen als p X0R q) reali¬ 
siert man in Modula mit p#q. Genauso läßt sich die Äquivalenz (»p genau dann wenn q«) 
mit p = q ausdrücken. 

4. Weil PALSE < TRUE ist, läßt sich die logische Implikation (»Wenn p, dann q« oder »aus p 
folgt q«) mit p< = q oder NOT p 0R q realisieren. 
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5. Weil FALSE<TRUE ist, können BOOLEAN-Variablen in FOR-Schleifen verwendet werden: 
FOR p : = FALSE TO TRUE DO <. . . > END; 

die Schleife läuft genau zwei Mal. 

6. Mit VAR b: BOOLEAN; sind folgende Ausdrücke korrekt: 

b: =FALSE; TRUE und FALSE sind vordefinierte Konstanten 

b: =5<7; ergibt TRUE 

b: =a#b; mit a,b vom Typ REAL 

b: = (10>2) AND (0<7); ergibt TRUE. 

7. Für den mathematischen Ausdruck 0<i<10 schreibt man in Modula: 

(0<i) AND ( i<10) (i vom Typ INTEGER) 

Das folgende Programm bringt eine Wahrheitstabelle der Form: 


p 

q 

p AND q 

p OR q 

NOT p 

p<= q 

falsch 

falsch 

falsch 

falsch 

wahr 

wahr 

falsch 

wahr 

falsch 

wahr 

wahr 

wahr 

wahr 

falsch 

falsch 

wahr 

falsch 

falsch 

wahr 

wahr 

wahr 

wahr 

falsch 

wahr 


MODULE WahrheitsTabelle; 

FROM InOut IMPORT WriteString, WriteLn, Read; 

VAR p, q : BOOLEAN; 
taste : CHAR; 

BEGIN 

WriteString(” p | q jp AND q | p OR q | NOT p | p <= q |”); 
WriteLn; 

WriteString (”-”); 

WriteLn; 

FOR p:=FALSE TO TRUE DO 
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FOR q:=EALSE TO TRUE DO 


IE p 

THEN WriteString(” 

wahr 

1») 

ELSE 

WriteString(” 

falsch 

I”) 

END; 

IE q 

THEN WriteString(” 

wahr 

!”) 

ELSE 

WriteString(” 

falsch 

1”) 

END; 

IE p & q 

THEN WriteString(” 

wahr 

1”) 

ELSE 

WriteString(” 

falsch 

1”) 

END; 

IE p OR q 

THEN WriteString(” 

wahr 

1”) 

ELSE 

WriteString(” 

falsch 

1”) 

END; 

IE NOT p 

THEN WriteString(” 

wahr 

1”) 

ELSE 

WriteString(” 

falsch 

1”) 

END; 

IF p <= q 

WriteLn 

THEN WriteString(” 

wahr 

1”) 

ELSE 

WriteString(” 

falsch 

I”) 

END; 


END 


END; 

Read(taste); 

END WahrheitsTabelle. 


1.3.6 Der Datentyp CHAR 

Dieser Typ dient zur Speicherung eines Zeichens (CHAR steht für character , »Zeichen«). Er 
umfaßt die Zeichen des ASCII ( American Standard Code for Information Interchanging, 
»Amerikanischer Code für Informationsaustausch«) und enthält noch einige Atari-spezifi¬ 
sche zusätzliche Zeichen. Zur Abspeicherung wird ein Byte verwendet, das macht 256 ver¬ 
schiedene Zeichen (die Zeichen sind im Anhang aufgelistet). Da der Typ CHAR durch die 
Binärdarstellung »durchnumeriert« ist, kann man alle Vergleichs-Operatoren auf CHAR- Aus¬ 
drücke anwenden. Aus demselben Grund können CHAR- Variablen auch in FOR-Schleifen ein¬ 
gesetzt werden. 

Folgende Standardfunktionen sind anwendbar: 

CAP(ch) Wenn ch ein Kleinbuchstabe ist, liefert CAP (ch) den entsprechenden Groß¬ 
buchstaben. Andere Zeichen behalten ihren Wert. 

DEC (ch ) erniedrigt ch (voriger ASCII-Wert). 

INC (ch ) erhöht ch (nächster ASCII-Wert). 

CHR( i) wandelt die CARDINAL-Zahl i in das i-te Zeichen des Zeichensatzes um. Bei¬ 
spiel: CHR( 65)ergibt ”A”. 

ORD(ch) ist die Umkehrfunktion zu CHR, es wird der ASCII-Wert des Zeichens zu¬ 
rückgegeben. Es gilt also (für i<256): 

CHR(ORD(ch))= ch und 
0RD(CHR(i))=i. 

Des weiteren liefert MIN (CHAR) und MAX (CHAR ) das kleinste bzw. größte Zeichen (CHR (0) und 
CHR( 255)). 
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In Modula kann ein Zeichen in drei Möglichkeiten dargestellt werden. Wir demonstrieren es 
hier am Großbuchstaben ”A”: 

1: WRITE (”A”); nur für druckbare ASCII-Zeichen 

2: WRITE(CHR( 65)); jedes beliebige Zeichen 
3: WRITE(101C); mit oktaler Zeichen-Konstante 

Beim letzten Punkt werden die Zeichen oktal durchnumeriert und ein »C« (für CHAR) ange¬ 
hängt. Die oktale Zahl »101« entspricht der Dezimalzahl 65 (1*8 2 + 0*8 + 1*1 = 65), also 
stellt 101C das 65. Zeichen dar, nämlich »A«. 

Ein kleiner Trick: Da die Ziffern 0,1,2...9 die aufeinanderfolgenden ASCII-Werte 48,49,...57 
haben, ist es möglich, ein Zahlzeichen in die entsprechende Ziffer umzuwandeln, also bei¬ 
spielsweise aus dem Zeichen ”3” die CARDINAL-Zahl 3 zu machen: 

i := ORD(ch) - 0RD(”0”); 

Das Einlesen einer CARDINAL-Variablen i funktioniert im Prinzip so: 
i : = 0; 

Read(ch); 

WHILE (”0” <= ch) AND (ch <= ”9”) DO 
i := 10 * i + ORD(ch) - 0RD(”0”); 

Read(ch) 

END; 

Das folgende Programm druckt die ASCII-Zeichen mit den Nummern 32 bis 255 aus; das sind 
die druckbaren Zeichen. Sie werden mit ihrem dezimalen und oktalen Werten angegeben. 

MODULE AsciiTabelle; 

PROM InOut IMPORT Write, WriteString, WriteCard, WriteNum, WriteLn, Read; 

VAR ch, taste : CHAR; 

BEGIN 

P0R ch : = ” ” T0 CHR(255) DO (* nur druckbare Zeichen *) 

WriteString(” ”); Write(ch); WriteString(” ”); 

WriteCard(ORD(ch),3); WriteString(” ”); (* ascii dezimal *) 

WriteNum(ORD(ch), 8, 3); WriteString(”C |”); (* oktal *) 

(* für andere Compiler: ’WriteOct(ORD(ch), 3)* statt 5 WriteNum. ..’ *) 

IP (ORD(ch) MOD 64 = 63) THEN Read(taste) END; 

IP (ORD(ch) MOD 4 = 3) THEN WriteLn END; 

END; 

END AsciiTabelle. 
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32 

48C 

i 

! 

$ 

36 

44C 


V. 

( 

48 

58C 


) 

t 

44 

54C 

i 

- 

8 

48 

68C 


i 

4 

52 

64C 


5 

8 

56 

78C 

i 

9 

< 

68 

74C 


= 

G 

64 

1B8C 

i 

8 

D 

68 

184C 

i 

E 

H 

72 

118C 


I 

L 

76 

114C 

i 

M 

P 

88 

128C 


Q 

T 

84 

124C 


U 

X 

88 

138C 


Y 

\ 

92 

134C 


] 

\ 

56 

148C 

i 

a 

d 

188 

144C 

i 

e 

h 

184 

158C 

i 

i 

1 

188 

154C 


n 

P 

112 

168C 


q 

t 

116 

164C 


u 

X 

128 

17BC 


y 

1 

124 

174C 

i 

> 

C 

128 

288C 

i 

ü 

ä 

132 

2B4C 

i 

ä 

e 

136 

218C 

i 

e 

t 

148 

214C 

i 

i 

t 

144 

228C 

i 

2 

ö 

148 

224C 

i 

0 

y 

152 

238C 


Ö 

£ 

156 

234C 


Y 

ä 

168 

248C 

i 

\ 

n 

164 

244C 


N 

l 

168 

258C 


p 

\ 

172 

254C 

i 

i 

ä 

176 

268C 

i 

0 

c 

188 

264C 

i 

(E 

ö 

184 

27BC 

i 


Sl 

188 

274C 


0 

u 

192 

3B8C 

i 

U 

a 

196 

384C 

i 

1 

T 

288 

31QC 


n 

3 

284 

314C 


7 

n 

288 

328C 

i 

11 

i« 

212 

324C 


1 

1 

216 

33BC 

i 

1 

1 

228 

334C 

i 

§ 

K 

224 

34BC 

i 

ß 

2 

228 

344C 

i 

<5 

5 

232 

350C 

i 

0 

0 

236 

354C 

i 

0 

8 

248 

36BC 


+ 

r 

244 

364C 


J 

6 

248 

37BC 


• 

n 

252 

374C 

i 

2 


33 

41C 

i 

ii 

34 

37 

45C 


& 

38 

41 

51C 


* 

42 

45 

55C 


, 

46 

45 

61C 

i 

2 

58 

53 

65C 

i 

6 

54 

57 

71C 

i 

• 

58 

61 

75C 

i 

> 

62 

65 

1B1C 

i 

B 

66 

69 

105C 

i 

F 

70 

73 

liiC 

i 

J 

74 

77 

115C 

i 

N 

78 

81 

121C 

i 

R 

82 

85 

125C 


V 

86 

89 

131C 

i 

Z 

50 

93 

135C 

i 

A 

94 

57 

141C 

i 

b 

58 

181 

145C 

i 

f 

102 

185 

151C 

i 

j 

106 

185 

155C 

i 

n 

110 

113 

1610 

i 

r 

114 

117 

1650 

i 

V 

118 

121 

1710 

i 

z 

122 

125 

1750 

i 


126 

125 

2010 


e 

130 

133 

2050 


ä 

134 

137 

2110 

i 

e 

138 

141 

2150 


B 

142 

145 

2210 


IE 

146 

145 

2250 


ü 

150 

153 

2310 

i 

ü 

154 

157 

2350 


0 

158 

161 

2410 


o 

162 

165 

2450 

i 

a 

166 

165 

2510 

i 


170 

173 

2550 

i 

« 

174 

177 

2610 

i 

0 

178 

181 

2650 

i 

fl 

182 

185 

2710 

i 


186 

185 

2750 

i 

0 

150 

193 

3010 

i 

X 

154 

157 

3050 


n 

198 

281 

3110 

i 

D 

202 

285 

3150 

i 

B 

206 

205 

3210 

i 

B 

210 

213 

3250 


HJ 

214 

217 

3310 

i 

D 

218 

221 

3350 


A 

222 

225 

3410 

i 

r 

226 

225 

3450 

i 

M 

230 

233 

3510 


ft 

234 

237 

3550 

i 

6 

238 

241 

3610 

i 

> 

242 

245 

3650 

i 

T 

246 

249 

3710 

i 


250 

253 

3750 

i 

3 

254 


420 

i 

n 

35 

430 

460 

i 

1 

35 

470 

520 


+ 

43 

530 

560 

i 

/ 

47 

570 

620 

i 

3 

51 

630 

660 

i 

7 

55 

670 

720 

i 

t 

55 

730 

760 

i 

? 

63 

770 

1020 

i 

C 

67 

1030 

1060 


G 

71 

1070 

1120 


K 

75 

1130 

1160 

i 

0 

75 

1170 

1220 


s 

83 

1230 

1260 

i 

w 

87 

1270 

1320 

i 

[ 

91 

1330 

1360 

i 

_ 

55 

1370 

1420 


c 

55 

1430 

1460 

i 

9 

103 

1470 

1520 

i 

k 

107 

1530 

1560 


0 

111 

1570 

1620 

i 

s 

115 

1630 

1660 


H 

115 

1670 

1720 

i 

{ 

123 

1730 

1760 


A 

127 

1770 

2020 

i 

a 

131 

2030 

2060 

i 

C 

135 

2070 

2120 


i 

135 

2130 

2160 

i 

B 

143 

2170 

2220 

i 

6 

147 

2230 

2260 


u 

151 

2270 

2320 


0 

155 

2330 

2360 


f 

155 

2370 

2420 

i 

ü 

163 

2430 

2460 

i 

0 

167 

2470 

2520 

i 

i 

171 

2530 

2560 


> 

175 

2570 

2620 

i 

0 

179 

2630 

2660 

i 

fl 

183 

2670 

2720 


T 

187 

2730 

2760 

i 

tM 

191 

2770 

3020 


1 

155 

3030 

3060 

i 

1 

159 

3070 

3120 

i 

■* 

203 

3130 

3160 

i 

J 

207 

3170 

3220 

i 

s 

211 

3230 

3260 

i 

n 

215 

3270 

3320 


5 

215 

3330 

3360 


00 

223 

3370 

3420 


ir 

227 

3430 

3460 

i 

r 

231 

3470 

3520 


5 

235 

3530 

3560 

i 

n 

239 

3570 

3620 

i 

< 

243 

3630 

3660 

i 

* 

247 

3670 

3720 


iT 

251 

3730 

3760 

i 


255 

3770 


Erweiterte ASCII-Tabelle 
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Die Zeichen ab Nummer 128 (also ab CHR(128)) gehören nicht mehr zur ASCII-Norm. Sie 
stimmen beim Atari weitgehend mit dem IBM-Zeichensatz überein, so daß IBM-kompatible 
Drucker die Mehrzahl dieser Zeichen richtig drucken können. Dies stimmt für die Umlaute, 
nicht aber für »ß«. 


Die Zeichen CHR(0)bis CHR(3l)(also die ersten 32) sind für bestimmte Steuerzwecke reser¬ 
viert. Sie lösen bei dem Gerät (Drucker, Bildschirm...) auf das sie ausgegeben werden, gewisse 
Funktionen aus. Bei einem Drucker kann man damit zum Beispiel den linken Rand einstellen 
oder den Zeichensatz wechseln (siehe Beispielprogramm »Druck« im Kapitel 4.4). 

Der Atari-Bildschirm emuliert die »Escape-Sequenzen« des VT52-Terminals. Eine solche Se¬ 
quenz wird durch das »ESC«-Zeichen (33C) und einem weiteren Zeichen ausgelöst und be¬ 
wirkt eine Aktion auf dem Bildschirm. Die Zeichen können mit zwei Write-Aufrufen ausge¬ 
geben werden. Beispielsweise löscht die Sequenz ESC-”E” den Bildschirm. In Modula pro¬ 
grammiert man dazu: 

Write(33C); Write(”E”); (*Write aus Terminal*) 

Wir haben die Escape-Sequenz ESC-”Y” bereits beim Schreiben der Prozedur GotoXY im 
Abschnitt 1.3.3 benutzt. 


Weitere interessante Escape-Sequenzen: 


ESC-”A” 

ESC-”B” 

ESC-”C” 

ESC-”D” 

ESC-”K” 

ESC-’T’ 

ESC-”e” 

ESC-”p” 

ESC-”q” 


bewegt den Cursor eine Zeile nach oben 
bewegt den Cursor eine Zeile nach unten 
bewegt den Cursor ein Zeichen nach rechts 
bewegt den Cursor ein Zeichen nach links 
löscht die Zeile ab der Cursorposition 
der Cursor wird unsichtbar 
der Cursor wird sichtbar 
bewirkt weiße Schrift auf schwarzem Grund 
hebt ESC-”p” auf 


1.3.7 Der Datentyp BITSET 

Dieser Datentyp repräsentiert die Menge {0,1,2,..., 15} (engl, set = dt. »Menge«, also BITSET: 
»Menge von Bits«). Er wird intern in 2 Byte abgespeichert. Jedes Bit steht für ein Element. Eine 
1 bedeutet, das Element ist vorhanden; eine 0, es ist nicht in der Menge. Die Menge 
{0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10, ll, 12,13,14,15}, die alle Elemente ihresTypes enhält, wird 
also mit llllllll llllllll dargestellt, die leere Menge {} mit dem Bitmuster 
00000000 00000000. Als Operatoren sind definiert: 
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+ Mengen Vereinigung: (2, 3}+ {3, 4} ergibt (2, 3, 4}. 

- Mengendifferenz: (2, 3}-{3, 4} ergibt {2}. 

* Mengendurchschnitt: {2, 3} * {3, 4} ergibt {3}. 

/ Symmetrische Differenz: {2, 3} / {3, 4} ergibt {2,4}. 

Der Operator IN bedeutet »ist enthalten in«, erwartet als Argumente ein CARDINAL-Element 
und eine BITSET-Menge und liefert als Ergebnis einen Wert vom Typ BOOLEAN. Alles klar? 
Eigentlich ganz einfach: der (Boolesche) Ausdruck 


a IN B entspricht mathematisch a e B. 

Beispiel: 3 IN {l, 2, 3} ergibt TRUE und 
3 IN {2,4, 6} ergibt FALSE. 

So kann man mit Mengen auch ein paar Formeln aufstellen: 


i IN (m + n) 

i IN (m - n) 

i IN (m * n) 

i IN (m / n) 


bedeutet (i IN m) OR (i IN n) 
bedeutet (i IN m) AND NOT (i IN n) 

oder so: (i IN m) > (i IN n) (nachdenken!) 

bedeutet (i IN m) AND (i IN n) 
bedeutet (i IN m) # (i IN n) 


Außerdem sind auf Mengen noch die Standardprozeduren INCL (Inklusion) und EXCL (Ex¬ 
klusion) anwendbar: 


nach m= {2, 3}; lNCL(m, 4) ist m gleich {2, 3, 4}, 
nach m= {2, 3}; EXCL(m, 3) ist m gleich {2}. 

Was kann man nun mit einem solchen Datentyp anfangen? 


Das Interessante an dem Typ BITSET ist, daß man auf einzelne Bits eines gespeicherten 
»Wortes« zugreifen kann. Ein »Wort« (engl, word )ist dabei eine Einheit aus zwei Bytes. Der 
Datentyp WORD ist in Modula definiert. Er ist zwar nicht Bestandteil der Sprache selbst, son¬ 
dern wird im Modul SYSTEM - auf den wir noch zu sprechen kommen - deklariert. Der 
WORD-Typ ist sehr flexibel: Man kann ihn jedem beliebigen 2-Byte-Typ zuweisen, also zum Bei¬ 
spiel CARDINAL, INTEGER oder BOOLEAN (bei Megamax). Dies funktioniert aber nur bei der 
Übergabe in der »Parameterliste einer Prozedur«. 


Eine Prozedur bezeichnet ein Unterprogramm. Das ist ein Programmteil, der durch Nennung 
seines Namens im »Hauptprogramm« abgearbeitet wird (»Prozeduraufruf«). Eine Prozedur 
kann eine Parameterliste haben. Darin sind die Daten (mit Typbezeichnung) aufgelistet, mit 
denen die Prozedur arbeitet. Prozeduren werden ausführlich in Abschnitt 1.5 behandelt. Das 
nachstehende Beispielprogramm verdeutlicht bereits das Prinzip. 
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Es geht hierbei darum, das bitweise »und«, »oder«, »entweder...oder« und »nicht« zu simulie¬ 
ren, daß sie vielleicht von C- oder Turbo-Pascal für ganze Zahlen her kennen. Schauen Sie sich 
an, wie elegant man das in Modula machen kann! 


MODULS BitSetTest; 

BROM SYSTEM IMPORT WORD; 

PROM InOut IMPORT Read, ReadCard, WriteCard, WriteLn, WriteString; 

PROCEDURE und (a,b : WORD) : WORD; 

BEGIN 

RETURN WORD(BITSET(a) * BITSET(b)) 

END und; 

PROCEDURE oder(a,b : WORD) : WORD; 

BEGIN 

RETURN WORD(BITSET(a) + BITSET(b)) 

END oder; 

PROCEDURE exOder(a,b : WORD) : WORD; 

BEGIN 

RETURN WORD(BITSET(a) / BITSET(b)) 

END exOder; 

PROCEDURE nicht(a:WORD) : WORD; 

BEGIN 

RETURN WORD(BITSET(MAX(WORD)) - BITSET(a)) 

END nicht; 

VAR i,j : CARDINAL; 

Taste : CHAR; 


BEGIN 

WriteString("Programm zum Testen von BITSET und der Mengenoperationen”); 
WriteLn; WriteLn; 

WriteString(”l. Zahl i : ”); ReadCard(i); 

WriteString(”2. Zahl j : ”); ReadCard(j); WriteLn; 

WriteString(”i und j = ”); WriteCard(CARDINAL(und (i,j)),5); 

WriteLn; 

WriteString(”i oder j = ”); WriteCard(CARDINAL(oder (i,j)),5); 

WriteLn; 

WriteString(”i exOder j = ”); WriteCard(CARDINAL(exOder(i,j)),5); 
WriteLn; 

WriteString("nicht i = ”); WriteCard(CARDINAL(nicht(i)),5); 
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Read(Taste) 
END BitSetTest. 


Beispiel: Die Eingabe i = 13 und j = 7 erzeugt: 


i und j =5 

i oder j =15 

i exOder j = 10 

nicht i = 65522 


Prüfen Sie diese Ergebnisse anhand der Bitmuster nach! 

Man sieht an dem Programm: 

1. Der Typtransfer zum Typ BITSET wird mit BITSET (var), wobei var eine beliebige 
2-Byte-Variable ist, erledigt. 

2. Die gesamte Bitmanipuliererei, die Sie von Lowlevel-Sprachen her kennen, ist bequem in 
Modula möglich! 

3. Für den Datentyp BITSET gibt es keine Ein- und Ausgabemöglichkeit. 

Wenn Sie sehen wollen, wie eine bestimmte Menge intern abgespeichert wird, hilft folgendes 
Vorgehen, mit dem man die interne Abspeicherung beliebiger 2-Byte-Variablen (CARDINAL, 
INTEGER, BITSET) erfassen kann. Wir verwenden wieder den Joker-Datentyp 
SYSTEM.WORD: 


MODULE BitMuster; 

EROM InOut IMPORT WriteLn, WriteString, Write, Read; 

PROM SYSTEM IMPORT WORD; 

PROCEDURE SchreibBits( w : WORD); 

VAR i : CARDINAL; 

BEGIN 

FOR i:=7 TO 0 BY -1 DO (* zunächst das untere Byte, *) 

IF i IN BITSET(w) THEN Write(”l”) ELSE Write(”0”) END 
END; 

Write(” ”); 

FOR i:=15 TO 8 BY -1 DO (* . . . dann das obere Byte *) 

IF i IN BITSET(w) THEN Write(”l”) ELSE Write(”0”) END 
END; 

END SchreibBits; 
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VAR c 
i 
b 

bs 

ch 


CARDINAL; 

INTEGER; 

BOOLEAN; 

BITSET; 

CHAR; 


BEGIN 

c := 5; WriteString(”5 intern: 

i := -1; WriteString(”-l intern: 

b := TRUE; WriteString(”TRUE intern: 

bs := {1,3,5}; WriteString(”{1,3,5} intern: 

Read(ch) 

END BitMuster. 




SchreibBits(c); WriteLn; 
SchreibBits(i); WriteLn; 
SchreibBits(b); WriteLn; 
SchreibBits(bs); WriteLn; 


Das Programm liefert folgende Ausgabe: 

5 intern: 00000000 00000101 

-1 intern: 11111111 11111111 

TRUE intern: 00000000 00000001 

{1,3,5} intern: 0010101000000000 

1.3.8 Zweck und Form einer Konstantendeklaration 

Wir haben bereits in den bisherigen Beispielprogrammen Konstantendeklarationen benutzt. 
Hier nur noch einmal eine Zusammenfassung und Vertiefung. 

Soll ein Bezeichner für einen festen Wert stehen, so muß er in einer Konstanten-Deklaration 
eingeführt werden. Eine Konstantendeklaration hat die Form 

C0NST 

bezeichnerl = Wertl; 
bezeichnet = Wert2; 


Die Werte sind dabei Konstanten von einem beliebigen einfachen Datentyp oder vom Typ 
ARRAY OF CHAR (eine Zeichenkette). 

Beispiele: 

CONST 

Pi = 3.1415926536; (* REAL-Konstante *) 
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PiHalbe = Pi / 2; (* 


MinusPi = - Pi; 

Zahll =5; (* 

Zahl2 = - 5; (* 

Zahl3 = 5D; (* 

Zahl4 = 5L; (* 

Zahl5 = - 5D; (* 

Zahl 6 = 5.0; (* 

Zahl7 = 5.0E6; (* 

Zahl8 = 5.1E-3; (* 

ok = TRUE; (* 

falsch = NOT ok; (* 

ESC = 33C; (* 

Glocke = 7C; (* 

Menge = {1,2,3}; (* 

Version = "Version 1.0” (* 

Strich = ”-” (* 

Zahl9 = 14B; (* 

ZahllO = 14H; (* 

Zahl11 = 0A1H; (* 

Zahl12 = INTEGER(3) (* 

Zahl13 = CARDINAL(5) (* 

Zahl14 = Zahll MOD Zahll2; 

Zeiger = NIL; (* 

Leer = MengenTyp{} (* 


REAL-Konstante, aus bereits 
definierten Konstanten können 
also neue Konstanten gebildet 
werden *) 

CARDINAL- oder INTEGER-Konstante *) 
INTEGER-Konstante *) 

LONGCARD- oder LONGINT- Konstante *) 
wie oben bei Megamax-Modula *) 
LONGINT-Konstante *) 

REAL-Konstante (Dezimalpunkt!) *) 
REAL-Konstante: 5000000.0 *) 
REAL-Konstante: 0.0051 *) 
BOOLEAN-Konstante *) 
BOOLEAN-Konstante *) 

CHAR-Konstante (Escape = CHR(27)) *) 
CHAR-Konstante *) 

BITSET-Konstante *) 

Zeichenkette *) 
wie oben *) 

CARDINAL- oder INTEGER-Konstante, 
oktale Angabe (= dezimal 12) *) 

CARDINAL oder INTEGER: hexadezimale 
Angabe (1*16 + 4*1 = 20) *) 

Zahlen müssen mit Ziffer beginnen! 
(10*16 + 1*1 = 161 dezimal *) 
INTEGER, keine CARDINAL-Konstante *) 
nur CARDINAL-Konstante *) 

POINTER-Konstante *) 

Menge, nicht vom Typ BITSET *) 


Wie man sieht, können bei der Konstanten-Deklaration auch Ausdrücke Vorkommen. 
Bei Zahll = 5 ist nicht klar, ob 5 als CARDINAL- oder INTEGER-Konstante gemeint ist. Ein 
vorangestelltes CARDINAL oder INTEGER legt aber den Typ fest. 

Folgendes ist nicht erlaubt: 

Zeichen=CHR(65); Funktionen dürfen nicht benutzt werden 
Zahll=-e; e muß vorher als Konstante definiert sein! 

Zahl2: =7L; »: =« ist falsch, es muß » = « heißen 

Zahl3=AlH; bei hexadezimal-Konstanten muß das erste Zeichen eine Ziffer sein 

(hier einfach eine 0 voranstellen). 
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Auf den Vorteil der Verwendung von Konstantendeklarationen wurde schon hingewiesen: 

1. Die Lesbarkeit des Programms erhöht sich. 

2. Der Programmtext läßt sich leichter abändern. Wenn zum Beispiel mehrfach im Pro¬ 
grammtext WriteString(”Version 1.0”) steht, so müßten bei einem Update alle Stel¬ 
len gesucht werden und der String ausgetauscht werden. Einfacher wäre es, die Konstante 
Version=”Version 1. 0” im Deklarationsteil zu ändern. 


1.4 Kontrollstrukturen 

Die bisherigen Beispielprogramme zeigen bereits des öfteren die Verwendung von Wiederho¬ 
lungsanweisungen (Schleifen) und bedingten Anweisungen. Man faßt die beiden Anweisungs¬ 
typen unter dem Oberbegriff »Kontrollstrukturen« zusammen, da sie erlauben, vom »linea¬ 
ren Programmablauf« (von »oben« nach »unten«) abzuweichen. Jetzt sollen die Kenntnisse 
über Kontrollstrukturen vertieft werden. 


1.4.1 Wiederholungsanweisungen 

Modula kennt vier verschiedene Schleifentypen, die mit den Schlüsselworten REPEAT, WHILE, 
LOOP und F0R eingeleitet werden. 

Die REPEAT-Schleife 

Diese Schleife hat die Form 
REPEAT 

<Anweisungs folge > 

UNTIL boolescher Ausdruck>; 

Zu deutsch etwa: Wiederhole <Anweisungsfolge> bis <Bedingung erfüllt>. 

Da die Abbruchsbedingung am Ende der Schleife getestet wird, wird eine REPEAT-Schleife 
mindestens einmal durchlaufen. Die Schleife 

REPEAT 

<Anweisungsfolge> 

OTTIL FALSE; 

ist eine »Endlosschleife.« Da FALSE natürlich immer »falsch« ist, wird die Abbruchsbedin¬ 
gung nie erfüllt und die Schleife hört nicht mehr auf. 
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In der Anweisungsfolge muß auf die Endebedingung eingewirkt werden, damit die Abbruchs¬ 
bedingung einmal true wird, sonst läuft die Schleife »ewig«. Die folgende Schleife druckt die 
ungeraden Zahlen von 1 bis 99: 

VAR i: CARDINAL; 


i ;= 1; 

(* i fängt bei 1 an *) 

REPEAT 


WriteCard(i,3); 

(* i ausdrucken *) 

INC(1,2) 

(* i um 2 erhöhen *) 

UNTIL i'= 101; 

(* letzte gedruckte Zahl ist 99 *) 


Nie erreicht würde hingegen die Abbruchsbedingung 
UNTIL i = 100; 

da i in der Schleife nur ungerade Werte annimmt. Man hätte hier - ungewollt - eine Endlos¬ 
schleife. 

Die Schleife 

REPEAT 

(* nix *) 

UNTIL KeyPressed(); 

läuft so lange, bis eine Taste gedrückt ist, sie wartet also auf einen Tastendruck. Besser ist die 
Lösung 

VAR taste : CHAR; 

READ(taste); 

da der Rechner während des Wartens noch andere Dinge (Drucker-Spooler) erledigen kann. 

Die WHILE-Schleife 

Dieser Schleifentyp ist vergleichbar mit der REPEAT-Schleife. Sie hat die Form 

WHILE boolescher Ausdruck> DO 
<Anweisungsfolge> 

END; 

Zu deutsch etwa: Solange <Bedingung> erfüllt ist, führe <Anweisungen aus. 

Im Gegensatz zur REPEAT-Schleife wird also das Abbruchskriterium am Anfang der Schleife 
geprüft. Dadurch kann es sein, daß die Schleife keinmal ausgeführt wird. Bei der Abbruchsbe- 
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dingung gibt es noch einen kleinen Unterschied: Die REPEAT-Schleife bricht ab, wenn die Ab¬ 
bruchsbedingung TRUE wird, die WHILE-Schleife, wenn die Abbruchsbedingung false wird 
(da sie läuft, solange die Bedingung erfüllt ist). Die Schleife 

WHILE TRUE DO <Anweisungen> END; 

ist also eine Endlosschleife. 

Die REPEAT-Schleife und die WHILE-Schleife kennen Sie schon von vorhergehenden Pro¬ 
grammen; daher erfolgt hier kein weiteres Beispiel. 

Die LOOP-Schleife 

Das englische Word loop heißt direkt übersetzt »Schleife«. Dieser Schleifentyp ist bis jetzt 
noch nicht vorgekommen. Es handelt sich um eine recht allgemeine Schleife. Die Abbruchs¬ 
bedingung kann nämlich irgendwo innerhalb des Anweisungsblocks stehen. Die Anweisung 
EXIT (engl, exit- »Ausgang«) beendet die Schleife. In einer LOOP-Schleife sind auch mehrere 
EXIT-Anweisungen möglich; die Schleife kann also mehrere Abbruchsbedingungen an ver¬ 
schiedenen Stellen haben: 

LOOP 

<Anweisungsf olgel > 

IF <JBedingungl> THEN EXIT END; 

<Anweisungsfolge2> 

IF <Bedingung2> THEN EXIT END; 

<Anweisungsfolge3> 

END; 

Wenn eine LOOP-Schleife keine EX IT-Anweisung enthält, hat man eine Endlosschleife. Mit der 
LOOP-Schleife lassen sich alle anderen Schleifen ausdrücken: 

Die REPEAT-Schleife 
REPEAT 

<Anweisungsfolge> 

UNTIL <Bedingung>; 

ist äquivalent zur folgenden LOOP-Schleife: 

LOOP 

<An we i s ungs folge > 

IF <Bedingung> THEN EXIT END; 

END; 
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Ebenso läßt sich die WHILE-Schleife: 

WRIIjE<Bedingung> DO 
<An weis ungs folge > 

END; 

umformen zur LOOP-Schleife: 

LOOP 

IF NOT <Bedingung> THEN EXIT END; 

<Anwei sungsf olge> 

END; 

Die LOOP-Schleife ist etwas primitiver als eine REPEAT- bzw. WHILE-Schleife. N. Wirth schreibt 
in seinem Buch [W1]: »Obwohl die LOOP-Anweisung in einigen Fällen bequem ist, sollte man 
im Normalfall doch besser eine WHILE- bzw. REPEAT-Anweisung verwenden, da diese deutli¬ 
cher eine einzige Endbedingung an einer syntaktisch offensichtlichen Stelle aufzeigen.« Wir 
folgen diesem Rat. 

Fragt sich, wozu die LOOP-Schleife überhaupt sinnvoll ist. 

Schauen wir uns dazu die Eingabeschleife aus dem Programm »Mittelwertberechnung« aus 
Abschnitt 1.3.4 an. Sie lautet in Kurzform 

REPEAT 

<Reelle Zahl einlesen> 

IF zahl #0.0 THEN 
<Zahl verarbeiten> 

END 

UNTIL zahl = 0.0; 

Dieselbe Zahl wird hier zweimal auf 0. 0 geprüft. Das läßt sich vereinfachen: 

LOOP 

<Eeelle Zahl einlesen> 

IF zahl =0.0 THEN EXIT END; 

<Zahl verarbeiten> 

END; 

Die FOR-Schleife 

Diese Wiederholungsanweisung ist sehr komfortabel, weil die Steuerung der Schleife (Initita- 
lisierung, Schrittweite und Abbruchskriterium) bereits im Schleifenkopf vorgegeben sind. Sie 
hat die Form 
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FOR <Zähler> := <Anfangswert> TO <Endwert> BY <Schrittweite> DO 
<An weis ungs folge > 

END 

»BY <Schri ttwei te> « kann entfallen. 

Wirkung: 

1. Die Laufvariable <Zähler> wird zu Beginn auf <Anfangswert> gesetzt. 

2. Es wird geprüft, ob der <Endwert> bereits überschritten ist, in dem Fall wird die Schlei¬ 
fe beendet. 

3. Ansonsten wird <Anweisungsfolge> ausgeführt. 

4. Anschließend wird die Laufvariable <Zähler> um <Schri ttwei te> erhöht. 

5. Es wird bei (2.) fortgefahren. 

Sind Anfangswert und Endwert gleich, so wird die Anweisungsfolge genau einmal abgearbei¬ 
tet. Ist bei positiver Schrittweite der Anfangswert höher als der Endwert, so wird die Schleife 
gar nicht durchlaufen. 

Die Schleife 

FOR ch : = ”A” TO ”Z” BY 2 DO 
WEITE(ch) 

END; 

entspricht 

ch := ”A”; 

WHILE ch <= ”Z” DO 
WRITE(ch); 

INC(ch,2) 

END; 


Es wird ACEGIKMOQSUWY ausgegeben. 

Bei einer FOR-Schleife kann die Zählvariable von einem beliebigen skalaren Typ (also 
CARDINAL, LONGCARD, INTEGER, L0NGINT, CHAR, BOOLEAN und Aufzählungstyp (vgl. Ab¬ 
schnitt 1.6.1)) sein. REAL ist nicht zulässig. Wie Sie aus der internen Darstellung von REAL- 
Variablen wissen, hat eine REAL-Zahl keinen direkten Nachfolger; daher ist auch INC für 
REAL nicht definiert (DEC ebenso nicht). 
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Die Schrittweite muß ein Ausdruck von Typ INTEGER oder CARDINAL sein. Sie kann auch 
ganz entfallen, als Schrittweite wird dann l angenommen. 

F0R <zähler> : = <Anfangswert> TO <Endwert> DO 
<An weis ungs folge > 

END 

Mit einer negativen Schrittweite (im einfachsten Fall -l) kann eine absteigende Schleife orga¬ 
nisiert werden (vgl. Prozedur SehreibeBits aus Abschnitt 1.3.7). 

Es ist zu beachten: 

Als Kontrollwerte für Anfangswert, Endwert und Schrittweite sind Ausdrücke zulässig. Fol¬ 
gende Einschränkungen gelten: 

• Die Kontrollwerte sollten innerhalb der Schleife nicht verändert werden. 

• Die Laufvariable < Zähler > wird von der FOR-Schleife kontrolliert. Sie darf innerhalb 
der Schleife ebenfalls nicht verändert werden; auf sie darf also nur »lesend« zugegriffen 
werden. 

• Nach Abarbeitung der FOR-Schleife ist der Wert der Laufvariablen als Undefiniert anzu¬ 


sehen. 


Folgendes ist also schlechter Stil und funktioniert bei verschiedenen Compilern unterschied¬ 
lich: 

MODULE SoNicht; 

FROM InOut IMPORT WriteLn, Read, WriteCard; 


VAR i : CARDINAL; 

taste : CHAR; 


BEGIN 

FOR i := 1 TO 100 BY 3 DO 


WriteCard(i,10); 

IF i = 10 THEN i := 90 END; 


(* ’lesender’ Zugriff ist ok! *) 
(* das tut man nicht! *) 


END; 

WriteLn; 

WriteCard(i, 10); 
Read(taste) 


(* auch das läßt man lieber sein! *) 


END SoNicht. 
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Wenn man Laufvariable nicht gleichmäßig erhöhen will, sollte eine Konstruktion mit anderen 
Schleifentypen vorgezogen werden. 


1.4.2 Bedingte Anweisungen 

Die IF-Anweisung 

Diese Anweisung wurde schon oft gebraucht. Ihre Varianten lassen sich am besten aus dem 
Syntax-Diagramm entnehmen: 


Expression 39 —►^THEfQ—► StatementSequence 14 


-K 


ELSIF ^ —► Expression 39 —► ^THEhT )—► StatementSequence 


14 


StatementSequence 14 




SYNTAX: ”IfStatement”(47) 


Beispiele: 

Der einfachste Fall ergibt sich: 

IF <Bedingung> THEN <Anweisungen END; 

Oder mit ELSE-Zweig: 

IE <Bedingung> 

THEN <Anweisungenl> 

ELSE <Anweisungen2> 

END; 

Das Pseudo-Programmstück 

IF <bl> THEN <Anweisungenl> 

ELSIF <b2> THEN <Anweisungen2> 

ELSIF <b3> THEN <Anweisungen3> 

ELSE <Anweisungen4> 

END; 
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bewirkt, daß Booleschen Ausdrücke <bl>, <b2>, <b3> nacheinander geprüft werden, bis 
einer von ihnen TRUE ergibt. Dann wird die entsprechende Anweisungsfolge ausgeführt und 
nach dem END fortgefahren. Sollten alle Booleschen Ausdrücke EALSE ergeben, so wird der 
ELSE-Zweig, also <Anweisungen4> ausgeführt. 

Das folgende (etwas fiktive) Beispiel demonstriert die Anwendung der IF-Anweisung: 

Ein milder Lehrer macht seine Noten auf folgende Weise: Er würfelt mit 3 Würfeln und nimmt 
die niedrigste der aufgetretenen Augenzahlen als Note. Wieviel Prozent Einser, Zweier, ... 
Sechser erteilt er? Wir simulieren dies mit Zufallszahlen: 

MODULE milderLehrer; 

PROM RandomGen IMPORT Randomize, RandomCard; 

PROM InOut IMPORT WriteCard, WriteReal, WriteLn, WriteString, KeyPressed; 

VAR 

wuerfell, wuerfel2, wuerfel3, anzahl, 

notel, note2, note3, note4, noteö, note6 : CARDINAL; 

PROCEDURE Schreibprozent(note : CARDINAL); (* kleiner Trick für Schreibfaule *) 
BEGIN 

WriteReal(PL0AT(note)*100.0 / PLOAT(anzahl), 6, 2); 

WriteString(); 

WriteLn 

END SchreibProzent; 

BEGIN 

WriteString(”Der milde Lehrer würfelt und würfelt, ”); 

WriteString(”bis Sie eine Taste drücken...”); 

anzahl:=0; notel:=0; note2:=0; note3:=0; note4:=0; noteö:=0; note6:=0; 

Randomize(12345); 

REPEAT 

wuerfell:=RandomCard(l,6); 
wuerfel2:=RandomCard(1,6); 
wuerfel3:=RandomCard(1,6); 

IP (wuerfell=l) OR (wuerfel2=l) OR (wuerfel3=l) THEN INC(notel) 

ELSIP (wuerfell=2) OR (wuerfel2=2) OR (wuerfel3=2) THEN INC(note2) 

ELSIP (wuerfell=3) OR (wuerfel2=3) OR (wuerfel3=3) THEN INC(note3) 

ELSIP (wuerfell=4) OR (wuerfel2=4) OR (wuerfel3=4) THEN INC(note4) 

ELSIF (wuerfell=5) OR (wuerfel2=5) OR (wuerfel3=5) THEN INC(noteö) 

ELSE INC(noteö) 

END; 

INC(anzahl); 
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UNTIL KeyPressed(); 

WriteLn; WriteLn; 

WriteString(”Anzahl der erwürfelten Noten insgesamt: 
WriteCard(anzahl, 10); 


WriteLn; WriteLn; 
WriteString("Einsen : ”); 
WriteString("Zweien : ”); 
WriteString(”Dreien : ”); 
WriteString("Vieren : ”); 
WriteString("Fünfen : ”); 
WriteString("Sechsen : ”); 
REPEAT UNTIL KeyPressed() 
END milderLehrer. 


SchreibProzent(notel); 
SchreibProzent(note2); 
SchreibProzent(note3); 
SchreibProzent(note4); 
SchreibProzent(noteö); 
SchreibProzent(note6); 



Ein Auswertungsbeispiel: 

Anzahl der erwürfelten Noten insgesamt: 24889 

Einsen : 41.88% 

Zweien : 27.77% 

Dreien : 17.52% 

Vieren : 8.98% 

Fünfen : 3.36% 

Sechsen : 0. 46% 

Dies stimmt gut mit den theoretischen Wahrscheinlichkeiten überein. 

Die CASE-Anweisung 

Man betrachte folgendes Programmstück zur Umwandlung eines römischen Zahlzeichens in 
eine Dezimalzahl: 

IF Zeichen = "M” THEN Zahl := 1000 
ELSIF Zeichen = "D” THEN Zahl : = 500 
ELSIF Zeichen = ”C” THEN Zahl := 100 
ELSIF Zeichen = ”L" THEN Zahl := 50 

ELSIF Zeichen = "X” THEN Zahl := 10 

ELSIF Zeichen = "V" THEN Zahl := 5 

ELSIF Zeichen = "I” THEN Zahl := 1 

ELSE Zahl := 0; 

Das sieht sehr umständlich aus und ist schreibintensiv. Modula-2 bietet hier die Fallunter¬ 
scheidung mittels CASE: 
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CASE Zeichen OE 



Zahl 

: = 

1000 

”D”: 

Zahl 

: = 

500 | 

”C”: 

Zahl 

: s 

100 | 

”L”: 

Zahl 


50 | 

”X”: 

Zahl 

: = 

10 | 

”V”: 

Zahl 


5 1 

”1”: 

Zahl 

: = 

1 

ELSE 

Zahl 

| = 

0 


END; 


Mit der CASE-Anweisung können also Verzweigungen von mehreren Fällen, die nur von ver¬ 
schiedenen Werten eines Ausdruckes abhängen, übersichtlich programmiert werden. Die 
CASE-Anweisung sieht allgemein so aus: 


— ^ CASE ^ —► Expression 39 OF ^ ^ ^ 


r 






CaseLabelList 24 

-o>* 

StatementSequence 14 






j 

- J 


^- ^ELSlT) —► StatementSequence 14 


—► 


SYNTAX: ”CaseStatement”(48) 


ConstExpr 27 



O 




O- 

ConstExpr 2 7 


j 


SYNTAX: ”CaseLabelList”(24) 
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Folgendes ist zu beachten: 

• Der Ausdruck nach dem CASE darf nur von den skalaren Typen (CARDINAL, INTEGER 
(auch LONGCARD, LONGINT), char, BOOLEAN sowie deren Aufzählungs- und Unterbe¬ 
reichstypen) sein. REAL-Typen sind (wieder einmal) nicht erlaubt! 

• Die Marken ConstExpr dürfen nur Konstanten von diesem Typ sein. Es sind jedoch 
mehrere Konstanten, die durch », « (Kommata) getrennt sind, erlaubt. Es können auch 
Bereiche als Marken angegeben werden: 4. . 7 steht für die Marken 4, 5, 6, 7. 

• Marken dürfen innerhalb einer CASE-Anweisung nicht doppelt Vorkommen! 

• Der ELSE-Zweig kann entfallen, wenn sichergestellt ist, daß durch den <Ausdruck> immer 
eine der Marken selektiert wird. Alle Anweisungsfolgen (auch die des ELSE-Zweiges) kön¬ 
nen leer sein, wenn an dieser Stelle nichts ausgeführt werden soll. 


Beispiel: 



CASE i 

OF 


1 

: <Anweisungenl> | 


2, 3 

; <Anweisungen2> \ 

(* Mehrere Marken sind erlaubt *) 

4. . 7 

: <Anweisungen3> 

(* Steht für 4,5,6,7 *) 

ELSE 

<An weisungen> 


END; 




Die CASE-Anweisung kann also nicht in jedem Fall eine geschachtelte IF-Anweisung ersetz¬ 
ten. Im Programm »milder Lehrer« des letzten Abschnittes ist die Fallunterschiedung nur 
durch Boolesche Ausdrücke und nicht durch Konstanten formulierbar. 

Das folgende Beispielprogramm wandelt römische Zahlen in arabische um. Die römischen 
Zahlen werden dabei als string (Zeichenkette) mittels ReadStringeingegeben. Wir benutzen 
dazu den Datentyp String aus dem Modul Strings. Aus diesem Modul stammt auch die 
Funktion Length, die die Länge eines Strings angibt. Ein String ist also eine Folge von Zei¬ 
chen. Auf das i-te Zeichen eines Strings s greift man mit s [ i ] zu. 

MODULE RoemischeZahlenKonvertierung; 

PROM InOut IMPORT ReadString, WriteString, WriteCard, WriteLn; 

PROM Strings IMPORT String, Length; 

VAR RoemZahlWort : String; 

AktuellZiffer, LetzteZiffer, zahl : CARDINAL; 

sub : BOOLEAN; 

: INTEGER; 


i 


(* subtrahieren *) 
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BEGIN 
REPEAT 
WriteLn; 

WriteString("RÖMISCHE ZAHL ( ’RETURN’ = ENDE ): ”); 
ReadString(RoemZahlWort); 

WriteLn; 
zahl:=0; 

LetzteZiffer:=0; 

POR i : = INTEGER(Length(RoemZahlWort)) - 1 TO 0 BY -1 DO 


GASE 

CAP(RoemZahlWort[i]) OP 

’M’ 

: Aktuellziffer 

: =1000| 

’D’ 

: AktuellZiffer 

: =500| 

’C’ 

: AktuellZiffer 

: =100! 

’L’ 

: AktuellZiffer 

: =50( 

’X’ 

: AktuellZiffer 

: =10| 

’V’ 

: AktuellZiffer 

:=5| 

’ I’ 

: AktuellZiffer 

: =1 


END; 

sub:=(LetzteZiffer>AktuellZiffer); 

IF sub THEN zahl:=zahl-AktuellZiffer ELSE zahl:=zahl+AktuellZiffer END; 
LetzteZiffer:=AktuellZiffer; 

END; 

WriteString(”In arabischerSchreibweise: ”); WriteCard(zahl,1); 

UNTIL zahl = 0; 

END RoemischeZahlenKonvertierung. 


Die Eingabe MCMLXXXIX liefert 1989. 

1.5 Das Prozeduren-Konzept 

1.5.1 Parameterlose Prozeduren 

Bei größeren Programmen ist es sinnvoll, das zu bearbeitende Problem in Teilaufgaben zu 
gliedern. Diese Teilaufgaben lassen sich in Modula als »Prozeduren« (Unterprogramme) 
formulieren. 

Eine Prozedur besteht aus 

1. dem Prozedur-Kopf: Er sieht bei paramterlosen Prozeduren so aus: 

PROCEDURE <ProzedurName>; 

wobei <ProzedurName> ein beliebiger (noch nicht benutzter und nicht reservierter) Be¬ 
zeichner ist. 
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2. einem Deklarationsteil: In ihm können wieder beliebige (und beliebig viele) Deklarationen 
folgen wie Konstanten- oder Variablen-Deklarationen (auch wieder Prozedur-Deklara¬ 
tionen und sogar lokale Module, vgl. 1.7.2!). 

3. BEGIN 

4. einer Anweisungsfolge 

5. END <ProzedurName>; 

wobei <ProzedurName> derselbe Name wie im Kopf sein muß. 

Das entspricht also dem Schema 

PROCEDURE <ProzedurName> ; 

<Deklarationen> 

BEGIN 

< Anweisungen> 

END <ProzedurName> ; 

Prozeduren werden im Deklarationsteil des Moduls (also vor dem eigentlichen Hauptpro¬ 
gramm) deklariert. Sie werden durch Nennung ihres Prozedurnamens in einer Anweisungs¬ 
folge aufgerufen. Dadurch wird die Abarbeitung des aufrufenden Programmstücks unterbro¬ 
chen und mit der Prozedur fortgefahren. Ist diese beendet, geht es mit der Anweisung weiter, 
die dem Prozeduraufruf folgt. Das Schema lautet also: 

MODULE <Modul-Name>\ 

CONST ... 

TYPE ... 

VAR ... 

PROCEDURE pl; 

CONST ... 

TYPE . . . 

VAR ... 

BEGIN 

<Anweisungsfolge> 

END pl; 

PROCEDURE p2; 

CONST ... 

TYPE ... 

VAR ... 

BEGIN 

<Anwe i sungs f olge > 

END p2; 
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BEGIN (* Hauptprogramm *) 

<Anweisungen> 
pi; 

<Anweisungen> 

p2; 

<An weisungen> 
pi; 

<Anweisungen> 

END <Modul-Name>. 

Prozeduren haben also bis auf das Semikolon am Ende die gleiche Form wie der Hauptmodul 
(am Ende des Hauptmoduls steht ein Punkt). 

Alle Bezeichner, die im Deklarationsteil einer Prozedur deklariert werden, sind nur innerhalb 
dieser Prozedur bekannt, also nur zwischen Prozedur-Kopf und dem dazugehörigen END. Ihr 
»Sichtbarkeitsbereich« (engl, scope) ist also auf die Prozedur beschränkt, in der sie definiert 
sind. Man nennt solche Bezeichner (Konstanten, Variablen, Typen, Prozeduren....) »lokal«. 
Die Bezeichner des Hauptprogramms sind dagegen »global«. Da letztere zwischen dem Mo¬ 
dul-Kopf und dem Modul-Ende (also im gesamten Modul) sichtbar sind, sind diese auch in 
allen dort definierten Prozeduren gültig. Nur wenn ein Bezeichner an einer Stelle »sichtbar« 
(gleichbedeutend mit »definiert« oder »bekannt«) ist, kann er dort benutzt werden. 

Folgendes muß man wissen: 

• Prozeduren können mehrmals aufgerufen werden. 

• Prozeduren können auch von anderen Prozeduren aufgerufen werden. 

• Bei Single-pass-Compilern (das sind solche, die den Programmtext in nur einem einzigen 
Durchgang lesen, dazu gehören Megamax und SPC) müssen Prozeduren vor ihrem ersten 
Aufruf deklariert sein. Das bedeutet, eine Prozedur kann keine Prozedur aufrufen, die im 
Programmtext erst weiter unten definiert wird. Eine Ausnahme ist mit der FORWARD- 
Deklaration möglich (siehe unten). 

• Eine Prozedur p2 kann auch innerhalb einer anderen Prozedur pl deklariert sein. p2 ist 
dann lokal zu pl. Die in pl definierten Bezeichner (Variablen etc.) sind dann »global« zu 
p2 (aber »lokal« zu pl); sind also in p2 sichtbar und können dort normal benutzt werden. 
Die Bezeicher des Hauptprogramms bleiben innerhalb p2 natürlich sichtbar. Die 
innerhalb p2 definierten Bezeichner (lokal zu p2) sind innerhalb pl nicht sichtbar und 
natürlich erst recht nicht im Hauptprogamm. p2 ist vom Hauptprogramm aus ebenfalls 
nicht sichtbar und kann von dort aus nicht aufgerufen werden. 

• Konstanten, Variablen oder Typen, die innerhalb einer Prozedur definiert werden (also 
»lokal« zu der Prozedur sind) dürfen den gleichen Namen tragen wie ein globaler Bezeich- 
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ner. Der globale Bezeichner ist dann innerhalb dieser Prozedur nicht mehr sichtbar, da der 
lokale Bezeichner Vorrang hat (sonst wäre die lokale Definition mit gleichem Namen 
wirkungslos). Der globale Bezeichner wird also durch einen lokalen Bezeichner mit 
demselben Namen »verdeckt«. 

• Benutzen Sie möglichst viele lokale Variablen. Sie entlasten das Hauptprogramm, bringen 
Übersicht und machen die Prozedur unabhängiger vom übrigem Programm. Merken sie 
sich den Spruch: »Soviel lokal wie möglich, so wenig global wie nötig« (manche Zeitgenos¬ 
sen wandeln diese goldene Regel um in »Soviel ins Lokal wie möglich, so wenig nach drau¬ 
ßen wie nötig...«). 

Zur FORWARD-Deklaration 

Falls eine Prozedur pl eine Prozedur p2 aufruft, die ihrerseits pi aufruft, muß pi die Pro¬ 
zedur p2 kennen und umgekehrt. Bei Single-pass-Compilern programmiert man dann: 

FORWARD PROCEDURE pl; (* Bei Megamax *) 

(* PROCEDURE pl; FORWARD; sonst *) 

PROCEDURE p2; 

BEGIN 
<. . . > 

pl; (* pl ist nach obiger FORWARD-Deklaration bekannt *) 

<. . . > 

END p2; 

PROCEDURE pl; 

BEGIN 
<. . . > 
p2; 

<. . . > 

END pl; 


Eine andere Möglichkeit wäre es, p 2 lokal zu pl zu deklarieren: 

PROCEDURE pl; 

PROCEDURE p2; 

BEGIN 
<. . . > 
pl; 

<. . . > 

END p2; 


(* pl ist bekannt *) 
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BEGIN 
<. . . > 

p2; (* p2 ist bekannt *) 

<■...> 

END pl; 


1.5.2 Prozeduren mit Parametern 

Prozeduren sind besonders dann praktisch, wenn man dieselben Anweisungsfolgen immer 
wieder an verschiedenen Stellen benötigt. Statt jedesmal die Anweisungen auszuschreiben, 
packt man sie einmal in eine Prozedur und ruft an den entsprechenden Stellen nur die Prozedur 
auf. 

Prozeduren können also Schreibarbeit ersparen und Codeverdopplung verhindern; gleichzei¬ 
tig helfen sie, das Gesamtproblem in logisch zusammenhängende Einheiten zu gliedern. 

Wir haben bereits davon in den Beispielen »BitSetTest« und »BitMuster« in Abschnitt 
1.3.7 sowie »milderLehrer« im vorigen Abschnitt Gebrauch gemacht. 

Während es im letzten Beispiel nur um Schreibersparnis ging, zeigt das erste Beispiel, daß Pro¬ 
zeduren auch Daten vom Hauptprogramm übermittelt bekommen können. Das ist nötig, 
wenn man zwar immer wieder dieselben Anweisungen benötigt, aber mit anderen Werten 
(»Parametern«) arbeitet. Dafür kann eine Prozedur eine »Parameterliste« erhalten; diese be¬ 
findet sich im Prozedurkopf hinter dem Prozedurnamen. Sie enthält die V ariablennamen (und 
deren Typen), in denen der Prozedur die Parameterwerte mitgegeben werden. 

Einige fertige Prozeduren sind bereits bekannt, wie WriteString aus dem Modul inOut, 
die eine Zeichenkette als Parameter besitzt. Nun lernen Sie selbst Prozeduren zu schreiben. 
Damit können sie quasi den Sprachumfang selbst erweitern! 

Als Beispiel dient die folgende Prozedur, die das Minimum zweier CARDINAL-Zahlen ausgibt: 

MODULE ProzedurDemol; 

PROM InOut IMPORT WriteCard, Read; 

PROCEDURE Minimum(n, m : CARDINAL); 

BEGIN 

IP n < m THEN WriteCard(n,1) ELSE WriteCard(m,1) END 
END Minimum; 
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VAR i, 3 : CARDINAL; 

taste : CHAR; 

BEGIN 

i : = 30; J := 50; 
Minimum(i,j); 
Read(taste) 

END ProzedurDemol. 


Der Prozedur Minimum werden also die Werte 30 und 50 »übergeben«. Man spricht von 
» W er teparameter n«. 

Intern geschieht das so: 

Beim Aufruf von Minimum ( i , j ) werden die Zahlen 30 und 50, also die Werte der Variablen 
iund j, in einen gesonderten Speicherbereich kopiert. Normalerweise ist dies der sogenannte 
Stack (»Stapel«). Dann springt die Programm-Ausführung zur Prozedur Minimum. Anhand 
der Parameterliste weiß die Prozedur, daß zwei Parameter und zwar CARDINAL-Zahlen vom 
Stack »abzuholen« sind. 

Mit diesen Parametern arbeitet die Prozedur. Falls die Prozedur diese verändert, passiert den 
Variablen i und j aus dem Hauptprogramm nichts, da die Prozedur ja nur mit einer Kopie 
von deren Werten arbeitet. 

Dazu ein weiteres Beispiel: 

M0DULE ProzedurDemo2; 

PROM InOut IMPORT WriteCard, WriteLn, Read; 

VAR i : CARDINAL; 

PR0CEDURE verdoppeln^ : CARDINAL); 

BEGIN 

n : = 2*n; 

WriteLn; WriteCard(n,1) 

END verdoppeln; 

VAR taste : CHAR; 

BEGIN 

i := 100; 
verdoppeln(i); 
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WriteLn; WriteCard(i,1); 
Read(Taste) 

END ProzedurDemo2. 


Die Prozedur WriteCardin verdoppeln gibt 200 aus, im Hauptprogramm 100. Die Varia¬ 
ble i wurde also im Hauptprogramm nicht verändert. 

Oft will man aber gerade eine solche Veränderung erreichen. Wendet man die Standardproze¬ 
dur INC beispielsweise auf eine CARDINAL-Variable an, so wird ihr Wert erhöht, also verän¬ 
dert. Nach der Sequenz 

n : = 5; 

INC(n); 

ist also n zu 6 verändert worden. Dieses Verhalten erreicht man durch Verwendung eines 
»VAR-Parameters«. Dazu steht das Schlüsselwort VAR in der Parameterliste: 

PROCEDURE verdoppeln(VAR n : CARDINAL); 

Wenn wir das auf unser Beispiel anwenden: 

MODULE ProzedurDemo3; 

PROM InOut IMPORT WriteCard, WriteLn, Read; 

PROCEDURE verdoppeln(VAR n : CARDINAL); 

BEGIN 

n : = 2*n; 

WriteLn; WriteCard(n, 1) 

END verdoppeln; 

VAR i : CARDINAL; 

taste : CHAR; 

BEGIN 

i := 100; 

WriteLn; WriteCard(i, 1); 
verdoppeln(i); 

WriteLn; WriteCard(i,1); 

Read(taste) 

END ProzedurDerao3. 
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Nun erzeugt es die Ausgabe 

100 

200 

200 

ist also nach Rückkehr von verdoppeln im Hauptprogramm verändert. Dies macht der 
Rechner so: Nicht der Wert, sondern die Adresse (das ist die Nummer der Speicherstelle, an 
der sich die betreffende Variable befindet) wird der Prozedur übergeben. Diese Adresse holt 
sich die Prozedur bei ihrem Aufruf. Sie arbeitet dann mit der betreffenden Speicheradresse 
und kann damit den Wert der Variablen des Hauptprogramms manipulieren. 

Die Skizze verdeutlicht die verschiedene Arbeitsweisen: 




Bild 1.13a: Prozedur mit Werteparameter Bild 1.13b: Prozedur mit VAR-Parameter 

Eine Prozedur mit VAR-Parametern kann aus diesem Grund nicht mit Konstanten aufgeru- 
fen werden. Beispielsweise würde verdoppeln ( 5 ) beim Kompilieren einen Fehler erzeugen. 

Eine Prozedur kann mehrere Parameter haben, es können dabei Werte und VAR-Parameter 
gemischt auftreten. Ein Beispiel dafür liefert die Standardprozedur INC in der Version mit 
zwei Parametern. Deren Definition kann man sich - hier für CARDINAL-Variablen - so vor¬ 
stellen: 

PR0CEDURE INC(VAR x: CARDINAL; n: CARDINAL); 

Durch den Aufruf von INC ( i, 5 ) wird i um den Wert 5 erhöht. 
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In der Prozedur 

PROCEDURE pl (x,y:CARDINAL; VAR u,v:INTEGER; ok: BOOLEAN); 

sind x, u, ok, Werteparameter und u, v VAR-Parameter. Die folgende Prozedur berechnet 
den ggT und kgV zweier CARDINAL-Zahlen und gibt sie als VAR-Parameter zurück: 

PROCEDURE kgVggT (a,b: CARDINAL; VAR kgV, ggT: CARDINAL); 

VAR 

rest, ab: CARDINAL; (* lokale Variablen *) 

BEGIN 

ab : = a * b; 

REPEAT 

rest := a MOD b; 
a : = b; 
b := rest 
UNTIL rest = 0; 
ggT : = a; 
kgV := ab DIV ggT 
END kgVggT; 


1.5.3 Funktionsprozeduren 

Die Standardprozedur CAP liefert zu einem Kleinbuchstaben den entsprechenden Groß¬ 
buchstaben. Mit CAP (ch) wird die Variable ch aber nicht verändert; den Großbuchstaben 
erhält man quasi aus dem Funktionsnamen CAP: 

Gross:=CAP(”a”); 

CAP nennt man daher eine »Funktions-Prozedur« oder kurz »Funktion«. 

Der Computer macht das so: Das Ergebnis der Funktion wird nach ihrer Abarbeitung an einer 
besonderen Stelle abgelegt, zum Beispiel in einem Register des 68000er Prozessors oder auf ei¬ 
nem Stack (bei Megamax, SPC). Bei der Wertzuweisung Gross: = CAP (”a”) erhält Gross 
diesen Wert. 

Eine Funktion kann immer nur ein Ergebnis haben. Sie können also im Beispiel des letzten 
Abschnittes nicht kgV und ggT mit einer Funktion zurückgeben. Der Kopf einer Funktion 
sieht so aus: 

PROCEDURE <FunktionsName> : <Typ-Bezeichner >; 

oder (mit Parametern) 
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PROCEDURE <FunktionsName> <ParameterListe> : <Typ-Bezeichner>\ 
Als Beispiel eine Funktion, die das Minimum zweier Zahlen zurückgibt: 

PROCEDURE Minimum(a,b: CARDINAL): CARDINAL; 

BEGIN 

IE a < b THEN RETURN a 
ELSE RETURN b 

END 

END Minimum. 


Die Anweisung i: =Minimum(3, 5) ergibt i=3. 

Das Beispiel BitSetTest in Abschnitt 1.3.7 enthält vier Funktionen vom Typ Word. 
Wichtig: 

• Funktionen liefern ein Ergebnis. Dieses muß auch »gelesen« werden, zum Beispiel 

i: =Minimum(3, 5) ; durch Zuweisen an eine Variable 

i: =3*Minimum(3, 5); durch Weiterverarbeiten 

WriteCard( Minimum(3, 5), 2); durch Übergabe an eine Prozedur. 

Nicht erlaubt ist einfach das Aufrufen wie eine Prozedur: 

Minimum (3,5); Der Compiler weiß hier nicht, wohin mit dem Ergebnis. 

• Der Wert, den eine Funktion als Ergebnis zurückgeben soll, wird hinter das Schlüsselwort 
RETURN geschrieben. Durch RETURN 5; wird zum Beispiel 5 zurückgeliefert (die Funk¬ 
tion »erhält den Wert« 5). Gleichzeitig wird die Funktion bei der RETURN-Anweisung 
beendet. Eine Funktion muß mindestens eine RETURN-Anweisung enthalten und durch 
eine RETURN-Anweisung beendet werden (also nicht mit IF eventuell daran vorbei¬ 
laufen), sonst bleibt der Funktionswert Undefiniert. 

• Beim Aufruf von Funktionen, die keine Parameterliste haben, muß hinter dem Namen 
dennoch eine »leere« Parameter-Liste »()« angegeben werden: 

x := ergebnis(); 

Falsch ist hier 

x := ergebnis; 

da diese Anweisung eine andere Bedeutung hat, auf die wir in 1.6.7 noch eingehen. 

Der korrekte Umgang mit Funktionen und Prozeduren ist sicherlich für den Anfänger ein 
harter Brocken. Sie können sich an den folgenden - nicht ganz fehlerfreien! - (Gegenbei¬ 
spielen selbst prüfen. Angenommen, Sie wollen eine Routine Low schreiben, die ähnlich wie 
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CAP arbeitet und zu einem Großbuchstaben den entsprechenden Kleinbuchstaben liefert, 
andere Zeichen aber nicht verändert (also das Gegenteil von CAP). 

Analysieren Sie die folgenden Versionen, die alle ordnungsgemäß kompiliert werden! Noch 
ein Hinweis. Kleinbuchstaben haben einen um 32 erhöhten ASCII-Wert wie der entspre¬ 
chende Großbuchstabe: 

CHR ( ORD (”A”) + 32) liefert ”a”. 

PROCEDURE Lowl(ch: CHAR); 

BEGIN 

IE (”A” <= ch) AND (ch <= ”Z”) THEN 
ch := CHR(ORD(ch) + 32)) 

END 

END Lowl; 

PROCEDURE Low2(VAR ch: CHAR); 

BEGIN 

IP (”A” <= ch) AND (ch <= ”Z”) THEN 
ch := CHR(ORD(ch) + 32)) 

END 

END Low2; 

PROCEDURE Low3(ch: CHAR): CHAR; 

BEGIN 

IF (”A” <= ch) AND (ch <= ”Z”) THEN 
RETURN CHR(ORD(ch) + 32)) 

END 

END Low3; 

PROCEDURE Low4(ch: CHAR): CHAR; 

BEGIN 

IF (”A” <= ch) AND (ch <= ”Z”) THEN 
RETURN CHR(ORD(ch) + 32)) 

ELSE 

RETURN ch 

END 

END Low4; 

PROCEDURE Low5(VAR ch: CHAR): CHAR; 

BEGIN 

IF (”A” <= ch) AND (ch <= ”Z”) THEN 
RETURN CHR(ORD(ch) + 32)) 

ELSE 
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RETURN ch 

END 

END Low5; 

PROCEDURE Low6(VAR ch: CHAR): CHAR; 
BEGIN 

IE (”A” < = ch) AND (ch <= ”Z”) THEN 
ch := CHR(0RD(ch) + 32)) 

END; 

RETURN ch 
END Low6; 


Wie sind diese Versionen zu bewerten? Lowl ist völlig unbrauchbar, da das Zeichen nicht als 
Funktionswert zurückgegeben wird. Da hier ch kein VAR-Parameter ist, bewirkt Lowl 
überhaupt nichts. 

Low2 macht zumindest etwas Sinnvolles: es wandelt das eingegebene Zeichen in einen Klein¬ 
buchstaben; das geht, weil hier ein VAR-Parameter benutzt wurde. Aber Low2 soll ja wie CAP 
arbeiten, also den Eingabewert unverändert lassen und den Kleinbuchstaben nur als Wert zu¬ 
rückliefern, sie muß daher als Funktion deklariert werden. Ein Aufruf wie 

Write(Low2(ch)); 

ist also unmöglich, man könnte sich bestenfalls mit 

Low2(ch); 

Write(ch); 

behelfen. 

Low3 ist fehlerhaft. Falls das übergebene Zeichen kein Großbuchstabe ist, erfolgt keine Er¬ 
gebniszuweisung (da dann kein RETURN aufgerufen wird). Der Compiler kann solche Fehler 
leider nicht melden, da er nicht so leicht feststellen kann, welche Fälle beim Ablauf auftreten 
können. Manche Systeme bemerken den Fehler aber während der Laufzeit! 

Die Funktion Low4 erfüllt die gestellten Anforderungen. Sie enthält zwei RETURN-Anwei- 
sungen; eine im THEN-Fall und eine im ELSE-Fall. Damit ist sichergestellt, daß immer (in 
jedem »Fall«) ein definierter Wert zurückgeliefert wird. Wenn das eingegebene Zeichen kein 
Großbuchstabe war, soll schließlich der urspüngliche Wert zurückgegeben werden. 

Low5 arbeitet ebenfalls korrekt, hat jedoch einen Haken. Die Deklaration des Parameters als 
VAR-Parameter ist überflüssig, da ch in der Funktion überhaupt nicht verändert wird. Au¬ 
ßerdem verhindert das, daß Konstanten übergeben werden können: 


klein := Low5(”A”); 
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wäre also nicht möglich. 

Die Funktion Low6 scheint richtig zu arbeiten, hat aber einen kleinen »Nebeneffekt«: Es ver¬ 
ändert die übergebene Variable gleich mit, da ch hier als VAR-Parameter deklariert ist. 
Wie bei Low5 sind hier keine Konstanten als Argumente möglich. Läßt man das VAR weg, 
läuft die Funktion fehlerfrei. 

Zum Schluß noch eine endgültige Version, die auch die Umlaute (Ä, Ö, Ü) richtig umwandelt: 

PROCEDURE Low(ch: CHAR): CHAR; 

BEGIN 

CASE ch OP 

”A”..”Z” : RETURN CHR(0RD(ch) + 32)) | 

”Ä” : RETURN ”ä” | 

”Ö” : RETURN ”ö” | 

”Ü” : RETURN ”ü” 

ELSE RETURN ch 
END 

END Low; 


Die verschiedenen Versionen sind auf der Diskette im Modul »PR0ZDEM4. M« enthalten. 

RETURN darf auch in Prozeduren, die keine Funktionen sind, zum vorzeitigem Abbruch be¬ 
nutzt werden. Dahinter darf dann jedoch kein Ausdruck stehen, da reine Prozeduren keinen 
Rückgabewert besitzen. Das folgende Beispiel finden sie auch auf der Diskette (Filename: 
»RETURN. M«:) 

PROCEDURE VorzeitigerAbhruch; 

VAR i: CARDINAL; 

BEGIN 

POR i := 0 TO 1000 DO 

IF i = 30 THEN RETURN END; 

WriteLn; WriteCard(i, 1); 

END 

END VorzeitigerAbhruch; 

Die Prozedur schreibt die Zahlen von 0 bis 29. Zugegeben, in diesem Beispiel ist der »brutale 
Ausstieg« aus Schleife und Prozedur nicht gerade die feine englische Art... 
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1.5.4 Rekursion 

Vielleicht kennen Sie die Werbung, in der ein Fernsehgerät gezeigt wird, in dem ein Fernseh¬ 
gerät gezeigt wird, auf dem wiederum ein Fernsehgerät gezeigt wird ... 

Dieser Effekt heißt »Bild im Bild« und läßt sich einfach dadurch realisieren, indem man eine 
Videokamera an den Fernseher anschließt (eventuell über einen Videorecorder als Adapter) 
und die Kamera dann auf den Fernseher (der das Kamera-Bild zeigen sollte) richtet. 

In Modula gehört so ein »Bild im Bild«-Effekt zu den sehr effizienten Programmierwerkzeu¬ 
gen. Zunächst betrachten wir einen normalen Aufruf zweier Prozeduren: 

Gegeben sei eine Prozedur A, die von einer Prozedur B aufgerufen wird, B wird vom Haupt- 
programm aus aufgerufen. Das Hauptprogramm wird dann beim Prozeduraufruf von B un¬ 
terbrochen; der Ablauf bei B weitergeführt. 

MODULE M; 

PROCEDURE A; 

BEGIN 

END A; 

PROCEDURE B; 

BEGIN 

A; 

END B; 

BEGIN (* M *) 

B; 

END M. 

Beim Aufruf von A wird B unterbrochen, und es folgt die Abarbeitung von A. Nach getaner 
Tat wird der Rest von B erledigt. Genauer werden diejenigen Anweisungen, die dem Proze¬ 
duraufruf von A folgen, ausgeführt. Ist auch das geschehen, wird der Rest des Hauptpro¬ 
gramms erledigt. 

Was passiert aber, wenn A und B identisch sind, das heißt, wenn B sich selbst aufruft? Analy¬ 
sieren wir das folgende Beispiel: 
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MODULE RekursionsTestl; 

PROM InOut IMPORT Read, Write, WriteString, WriteLn; 

PROCEDURE Zeichen; 

VAR ch : CHAR; 

BEGIN 

Read(ch); 

IP ch # THEN Zeichen END; 

Write(ch) 

END Zeichen; 

VAR taste : CHAR; 

BEGIN 

WriteString(”Geben Sie einige Zeichen ein, Punkt zum Abschluß!”); 
WriteLn; 

Zeichen; 

Read(taste) 

END RekursionsTestl. 


Gibt man nacheinander »123. « ein, so erhält man auf dem Bildschirm 

123..321 

Wieso? 

Das Hauptprogramm ruft die Prozedur Zeichen auf, die erste Anweisung lautet 
Read(ch). Die eingegebene 1 wird auf dem Bildschirm »geechot«. Da l ungleich ». « ist, 
wird wiederum Zeichen aufgerufen. Der Rechner »merkt« sich aber, daß von der Prozedur 
Zeichen vom ersten Aufruf noch ein Rest abzuarbeiten ist. Nun geben wir eine 2 ein. 
Wiederum wird Zeichen aufgerufen, da 2 ungleich ». « ist. Wir geben noch »3« und ». « in 
gleicher Weise ein. Auf dem Bildschirm steht bis jetzt: 

123. 

Nun erfolgt die Abarbeitung des Prozedurrestes. Write (ch) schreibt also das letzte eingege¬ 
bene Zeichen, also ». « noch einmal auf den Bildschirm. Dieser letzte Prozedur-Aufruf ist jetzt 
beendet. Nun ist aber noch der Rest vom dritten Aufruf abzuarbeiten. Hier war ch= 3, also 
wird als nächstes eine 3 aufgeschrieben. Der Rest des zweiten Aufrufes erzeugt die 2, der Rest 
des ersten Aufrufes die l. Somit sind alle Prozeduraufrufe abgearbeitet, und der Rest des 
Hauptprogramms folgt. 
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Zum besseren Verständnis beachte man, daß für eine lokale Variable einer Prozedur (hier ch) 
bei jedem Aufruf der Prozedur Speicherplatz bereitgestellt wird. Der Wert einer lokalen Varia¬ 
blen wird erst dann »vergessen«, wenn die Prozedur verlassen wird. Daher kennt Zeichen 
zu guter Letzt auch noch die abschließende 1. Ändern Sie das Programmm einmal ab, indem 
Sie die Zeile VAR ch: CHAR; vor die Prozedur Zeichen setzen, also als globale Variable de¬ 
klarieren. Finden Sie heraus, was nun bei der obigen Eingabe passiert! 

Diesen »Selbstaufruf« einer Prozedur nennt man Rekursion. Die Skizze macht das Verfahren 
deutlich: 


1. Aufruf von 
'Zeichen’ 
ch = -r 


ungleich V 
also:. 


> 


2. Aufruf von 
'Zeichen’: 
ch = "2" 


ungleich V 
also. 


> 


3. Aufruf von 
'Zeichen’: 
ch = •3- 


ungleich V 
also: . 


r \ 

4. Aufruf von ‘Zeichen’: 
ch = V also : Writef“.") 

v_y 


Abarbeitung des Restes des 3. Aufrufs: 
Write(-3") 




Abarbeitung des Restes des 2. Aufrufs: 
Writep2’) 


Abarbeitung des Restes des 1. Aufrufs: 
Writepl") 


Bild 1.14: Prinzip der Rekursion 

Eine Kette von Selbstaufrufen muß natürlich einmal abbrechen, hierzu dient die IF-Anwei- 
sung! Diese Abbruchsbedingung ist also ein wesentlicher Bestandteil von rekursiven Prozedu¬ 
ren! Sie kann in der Mitte der Prozedur liegen: 
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PROCEDURE rek; 

BEGIN 

<Anweisungsfolge vor Rekursion> 

IP <Bedingung> THEN rek END; 

<Anweisungsfolge nach Rekursion> 

END rek; 

Damit erhält man die Abarbeitungsreihenfolge: 

Av x , Av 2 , Av 3 Av n (Bedingung falsch) An n ,..., An 3 , An 2 , An x 

dabei bedeutet 

Av i = Anweisungsfolge vor Rekursion im i-ten Aufruf und 
An i = Anweisungsfolge nach Rekursion im i-ten Aufruf 

Av oder An können auch leer sein 

Beispiele rekursiver Funktionen 

Rekursion ist ein machtvolles Programmierwerkzeug, da mit ihr Sachverhalte, die »rekursi¬ 
ven Charakter« haben, in natürlicher Weise formuliert werden können. 

Wir greifen einige Beispiele der vorangegangenen Abschnitte auf: 

Zur ggT-Berechnung (vgl. Modul DrittesBeispiel aus Abschnitt 1.1): 

Es gilt: 

(1) ggT(i,j) = i, falls i = j 

(2) ggT(i,J) = ggT(i - j,j), falls i > j 

(3) ggT(i,j) = ggT(i,J - i), falls i < j 

Das setzt man wie folgt in Modula um: 

MODULE RekursionsTest2; 

PROM InOut IMPORT ReadCard, WriteCard, WriteString, WriteLn; 

PROCEDURE ggT(a,b : CARDINAL) : CARDINAL; 

BEGIN 

IP a = b THEN RETURN a 

ELSIP a > b THEN RETURN ggT(a-b,b) 

ELSE RETURN ggT(a,b-a) 

END 

END ggT; 
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VAR i,j : CARDINAL; 

BEGIN 

REPEAT 

WriteString(”Geben Sie eine natürliche Zahl ein : ”); ReadCard(i); 
WriteString(”Noch eine, bitte ( 1 = Ende ) : ”); ReadCard(j); 

WriteLn; 

WriteString(”Der ggT dieser beiden Zahlen lautet: ”); 
WriteCard(ggT(i,j),1); 

WriteLn 
UNTIL j = 1 
END RekursionsTest2. 


Bei diesem Beispiel gibt es keine eigentlichen Anweisungsfolgen vor oder nach der Rekursion 
(bzw. sie sind leer). Der Algorithmus stimmt trotzdem, da die Zahlen aund b dauernd durch 
die Aufrufe in der Rekursion erniedrigt werden. 

Vor einem Prozeduraufruf muß im Computer für die gerufene Prozedur Speicherplatz für 
lokale Variablen und Werteparameter der Prozedur angelegt werden. Dann erst wird sie betre¬ 
ten. Dies nennt man dann eine Inkarnation (dt.: etwa »Fleischwerdung«). Ruft sich eine Pro¬ 
zedur selbst auf, so hat man eine neue Inkarnation dieser Prozedur. Jede Inkarnation hat ihre 
eigenen lokalen Variablen und Parameter. Insofern sind auch die Werte a und b in jeder In¬ 
karnation verschieden! Globale Variablen und VAR-Parameter werden natürlich nicht neu 
angelegt, ihre Werte werden gegebenenfalls überschrieben. 

Ein weiteres klassisches Beispiel ist die Fakultätsberechnung (vgl. auch Abschnitt 1.3.2). Es 
gilt die rekursive mathematische Definition: 

1. 0! = 1 sowie 

2. n! = n * (n-1 ) ! für n > 0 

Dies spiegelt sich in der rekursiven Fassung der Prozedur Pakul taet wieder. 

MODULE RekursionsTest3; 

PROM InOut IMPORT ReadCard, WriteCard, WriteString, WriteLn; 

PROCEDURE Pakultaet(n : CARDINAL) : CARDINAL; 

BEGIN 

IF n <= 1 THEN RETURN 1 ELSE RETURN n*Fakultaet(n-1) END 
END Pakultaet; 
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VAR i : CARDINAL; 

BEGIN 

REPEAT 

WriteString("Geben Sie eine Zahl (0 <= n <= 8 ) ein ( 0 « Ende): ”); 
ReadCard(i); WriteLn; 

WriteString(”Es gilt: ”); WriteCard(i,1); WriteString(”! = ”); 
WriteCard(Eakultaet(i),1); WriteLn 
UNTIL 1 = 0 
END RekursionsTest3. 


Berechnen Sie Fakultaet(5). Es sollte 120 herauskommen. Betrachtet man die Prozedur 
Fakultaet, so hat es den Anschein, als könne die Multiplikation nicht ausgeführt werden, 
weil der zweite Faktor Pakul tae t ( n-1 ) ja noch gar nicht berechnet worden ist. Der Rechner 
organisiert das folgendermaßen: Bei jedem Aufruf von Fakultaet (n-l ) merkt der Rechner 
sich die Stelle, wo er bei n*. . . aufgehört hat. Ist durch die mehrfache Erniedrigung von n 
um eins schließlich 1 erreicht, so ist der Wert Fakultaet ( 1 ) bekannt, und die Multiplikation 
2*1 kann sofort ausgeführt werden. Es folgt dann der Rücksprung zu der Multiplikation 
von 3*, der Rechner rechnet also 3*2*1 usw. bis schließlich alle Aufrufe abgearbeitet sind 
und das Ergebnis 5*4*3*2*1 = 120 feststeht. Insgesamt hat sich die Prozedur hier fünfmal 
selbst aufgerufen. Man sagt, die Rekursionstiefe ist 5. 

Im nächsten Beispiel wird die Nullstelle der Funktion 

f(x) = x -cos(x), x im Bogenmaß (»Radiant«) 

im Intervall [a, b] = [0,1] rekursiv ermittelt. Weil 

f(0)<0 und f(l)>0 

gilt, wird geprüft, ob der Funktionswert in der Intervallmitte positiv oder negativ ist. Im ersten 
Fall wird im Intervall [a, (a+b)/2] im zweiten Fall im Intervall [(a+b)/2,b] weiterge¬ 
sucht. Diese Berechnung wird solange fortgeführt, bis die Länge des Suchintervalls einen ge¬ 
wissen Wert unterschritten hat. 
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Fakultaet(5) 

i_ 



> 


Fakultaet(4) 


L 


r 


Fakultaet(3) 


L 


r 


Fakultaet(2) 

L_ 


r 


Fakultaet(l) = 1 
1 


j 


Ergebnis: 

Fakultaet(5)= i*2*3*4*5 = 120 


Bild 1.15: Fünf Inkarnationen von »Fakultaet« 


MODULE RekursionsTest4; 

FROM InOut IMPORT WriteReal, WriteString, Read; 
FROM MathLibO IMPORT cos; 

CONST epsilon = 1.0E-10; 

PROCEDURE f(x : REAL) : REAL; 

BEGIN 

RETURN x - cos(x) 

END f; 
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PROCEDURE Nullstelle(VAR a, b : REAL) : REAL; 

VAR mitte : REAL; 

BE6IN 

mitte := (a + b) / 2.0; 

IE ABS(a-b) < epsilon THEN RETURN mitte 

ELSIP f(mitte) <0.0 THEN RETURN Nullstelle(mitte, b) 

ELSE RETURN Nullstelle(a,mitte) END 
END Nullstelle; 

VAR xl,x2 : REAL; 
taste : CHAR; 

BEGIN 

xl : = 0. 0; x2 : = 1. 0; 

WriteString(”Die Nullstelle von ’ f(x) = x - cos(x)’ lautet: ”); 
WriteReal(Nullsteile(xl,x2), 12,10); 

Read(taste) 

END RekursionsTest4. 


Man erhält das Ergebnis 0. 7390851332. 

Die Prozedur Nullstelle läßt sich natürlich auch »iterativ« (also nicht rekursiv, sondern 
mit einer Schleife) fassen: 

PROCEDURE Nullstelle(a,b: REAL): REAL; 

VAR mitte: REAL; 

BEGIN 

REPEAT 

mitte := (a + b) / 2.0; 

IF f(mitte) <0.0 
THEN a : = mitte 
ELSE b := mitte 
END; 

UNTIL ABS(a-b) < Toleranz: 

RETURN mitte 
END Nullstelle; 


Das komplette Programm ist auf der Diskette unter dem Namen »NULL I TER. M« vorhanden. 
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Die Schwächen von Rekursionen 

Wir bringen ein weiteres klassisches Beispiel: 

Leonardo von Pisa, genannt Fibonacci, formulierte in seinem 1202 erschienenen Buch »über 
abaci« die berühmte Kaninchenaufgabe: 

»Zur Zeit 0 hat man ein Kaninchenpaar. Nach 2 Monaten erzeugt dieses Kaninchenpaar jeden 
Monat ein neues. Die Nachkommen befolgen auch dieses Gesetz. Wieviele Paare hat man 
nach n Monaten?« 


Bezeichnet man die Anzahl der Kaninchen zur Zeit n mit Fibonacci (n), so gilt offenbar: 


(1) Fibonacci(O) 

(2) Fibonacci(l) 

und 

(3) Fibonacci(n) 



Fibonacci(n-1) + Fibonacci(n-2) 


T 

Paare, die schon 
da sind (gestor¬ 
ben wird nicht). 


t 

Kaninchen¬ 
paare, die schon 
mindestens zwei 
Monate alt sind, 
haben ein neues 
Paar erzeugt. 


Die jeweils nächste Zahl erhält man also einfach durch Addition der letzten beiden: 

1 , 1 , 2 , 3 , 5 , 8 , 13 , 21 , 34 , 55 , 89 , .. . 

In der folgenden Realisation messen wir die Rechenzeiten mit einer »Stoppuhr«, die wir in 
Kapitel 3 erläutern. 

Vor jeder Berechnung wird die Uhr durch Stoppuhr. Start auf Null gestellt, nach jeder Be¬ 
rechnung liest man die Zeit in Millisekunden mittels Stoppuhr. Lesen( ). Unsere Stoppuhr 
hat eine Auflösung von 5 ms. 

Wir benutzen hier zum erstenmal einen Modul in der Importliste, der nicht vom Megamax- 
System mitgeliefert wurde, sondern von uns stammt. Vor der Übersetzung des Programms 
muß dem System die Übersetzung des Moduls Stoppuhr bekannt sein! Diese Übersetzung 
finden Sie in dem Ordner »OBJEKTE« . Bevor Sie mit der Kompilation von »REKUTES5 . M« be¬ 
ginnen, muß dem Compiler der Suchpfad für »OBJEKTE« bekannt gemacht werden. Hierzu ist 
die Datei »SHELL. INF« entsprechend zu edieren (vgl. Handbuch). Wenn sie nicht das Mega- 
max-System benutzen, streichen Sie einfach die Stoppuhr-Aufrufe. 
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MODULE RekursionsTest5; 

FROM InOut IMPORT WriteCard, WriteString, WriteLn, Read, RedirectOutput; 
IMPORT Stoppuhr; 

PROCEDURE Fibonacci(n : CARDINAL) : CARDINAL; 

BEGIN 

IF n <= 1 THEN RETURN 1 

ELSE RETURN Fibonacci(n-1) + Fibonacci(n-2) END 
END Fibonacci; 

VAR i, fib : CARDINAL; 
zeit : LONGCARD; 
taste : CHAR; 

BEGIN 

RedirectOutput(”PRN: ”, FALSE); (»Streichen wenn kein Drucker vorhanden *) 
WriteString(” i | Fibonacci(i) | Zeit in Millisekunden”); WriteLn; 

WriteString(”-”); WriteLn; 

FOR i := 0 TO 23 DO 

WriteCard(i,3); WriteString(” |”); 

Stoppuhr.Start; fib:=Fibonacci(i); zeit := Stoppuhr.Lesen(); 

WriteCard(fib,10); WriteString(” |”); WriteCard(zeit, 13); WriteLn 

END; 

Read(taste) 

END RekursionsTestö. 


Die Ausgabe wird mit InOut. RedirectOutput auf den Drucker (»PRN :«, wie engl. 
printer= »Drucker«) umgeleitet. Falls kein Drucker angeschlossen ist, muß dieser Prozedur¬ 
aufruf unterbleiben! 
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i Fibonacci(i) Zeit in Millisekunden 


0 

1 

0 

1 

1 

0 

2 

2 

0 

3 

3 

0 

4 

5 

0 

5 

8 

0 

6 

13 

0 

7 

21 

5 

8 

34 

5 

9 

55 

5 

10 

89 

10 

11 

144 

10 

12 

233 

15 

13 

377 

30 

14 

610 

45 

15 

987 

80 

16 

1597 

130 

17 

2584 

205 

18 

4181 

340 

19 

6765 

545 

20 

10946 

880 

21 

17711 

1425 

22 

28657 

2305 

23 

46368 

3730 


Die Stoppuhr hat eine Auflösung von 5 ms (Millisekunden). Man erkennt, daß auch die 
Rechenzeiten in etwa die Rekursions-Formel 

Zeit(n) = Zeit(n-l) + Zeit(n-2) 

befolgen. Woran liegt das? Der Aufruf von Fibonacci (5) erzeugt die folgenden Aufrufe, die 
wir in einem »Baum« darstellen: 
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Insgesamt wird Fibonacci hier schon 15 mal aufgerufen! Wir haben also bei einer Rekur¬ 
sionstiefe von nur 5 bereits 15 Inkarnationen von Fibonacci: 
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Bild 1.17: Rekursive Aufrufe von Fibonacci 


Die iterative Version von Fibonacci ist etwas umständlicher. Sie erzeugt aber Rechenzeiten, 
die so kurz sind, daß sie mit unserer Stoppuhr nicht gemessen werden können, da sie unter 5 ms 
liegen: 

MODULE EibonacciFolgelterativ; 

FROM InOut IMPORT RedirectOutput, WriteCard, WriteString, WriteLn, Read; 

PROM Stoppuhr IMPORT Start, Lesen; 


PROCEDÜRE Eibonaccilter(n : CARDINAL) : CARDINAL; 
VAR i, neuer, letzter, vorletzter : CARDINAL; 
BEGIN 
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IP n <= 1 THEN RETURN 1 ELSE 
letzter := 1; vorletzter := 1; 

FOR i := 2 TO n DO 

neuer := letzter + vorletzter; 
vorletzter := letzter; 
letzter := neuer 
END; 

RETURN neuer 
END 

END Fibonaccilter; 

VAR i, fib : CARDINAL; 
zeit : LONGCARD; 
taste : CHAR; 

BEGIN 

RedirectOutput(”PRN:”,FALSE); 

WriteString(” i | Fibonacci(i) | Zeit in Millisekunden”); WriteLn; 

WriteString(”-”); WriteLn; 

FOR i := 0 TO 23 DO 

WriteCard(i,3); WriteString(” |”); 

Start; fib:=FibonacciIter(i); zeit := Lesen(); 

WriteCard(fib, 10); WriteString(” |”); WriteCard(zeit, 13); WriteLn 
END; 

Read(taste) 

END FibonacciFolgelterativ. 


Im Prinzip läßt sich zu jeder rekursiv formulierten Prozedur eine iterative Version angeben. 
Bei Prozeduren, die vor oder nach der Rekursion keine Anweisungsfolgen haben, ist das im¬ 
mer ohne Umstand möglich; andernfalls muß man ein wenig mit einer Stapelverwaltung trick¬ 
sen. Wir gehen im Abschnitt 2.2.1 darauf ein. Im ersteren Fall sind die iterativen Fassungen 
immer deutlich schneller als die rekursive, da bei der Rekursion noch eine zeitaufwendige 
Speicherung von Rücksprungadressen, lokalen Variablen und Parametern (halt die Inkarna¬ 
tion) erfolgt. 

Bei großer Rekursionstiefe können sehr viele Inkarnationen entstehen (siehe Fibonacci), die 
noch auf ihre Abarbeitung warten. Dabei kann irgendwann der Speicherplatz zu knapp wer¬ 
den. Das Programm bricht dann mit irgendeiner unschönen Meldung wie »Stacküberlauf« ab! 

Warum überhaupt noch Rekursion? 

Als Faustregel gilt: Immer dann, wenn das Problem in rekursiver Definition vorliegt, ist eine 
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rekursive Umsetzung leicht zu programmieren und vor allem leicht zu verstehen. Bei einer ein¬ 
fachen Rekursion, wo sich die rekursive Prozedur nur einmal selbst aufruft (bei Fibonacci 
war es zweimal!), wird die Abarbeitung nicht deutlich langsamer sein, und bei kleinen Rekur¬ 
sionstiefen kommt es wohl kaum zu einem Stack-Überlauf. Man sollte sich also als Program¬ 
mierer über die mögliche Rekursionstiefe Klarheit verschaffen. 

Rekursion ist insbesondere dann angesagt, wenn sich die Datenstruktur bereits rekursiv defi¬ 
nieren läßt. Solche Datenstrukturen werden wir in Kapitel 2 betrachten. Dort folgen also noch 
ernsthafte Beispiele, die die vorteilhafte Anwendung von Rekursionen zeigen. 

Beispiele mit großer Rekursionstiefe 

Wir schließen das Kapitel mit zwei extremen Beispielen: Das erste Programm zeigt eine rekur¬ 
sive Definition der Potenzfunktion von ganzen Zahlen, die auf eine rekursiver Multiplikation 
und diese wieder auf eine rekursive Definition der Addition zurückgreift: 

MODULE RekursionsTestö; 

FROM InOut IMPORT ReadCard, WriteCard, WriteString, WriteLn; 

PROCEDURE add(a,b : CARDINAL) : CARDINAL; 

BEGIN 

IF b = 0 THEN RETURN a ELSE RETURN add(a,b-l) + 1 END 
END add; 

PROCEDURE mult(c,d : CARDINAL) : CARDINAL; 

BEGIN 

IF d = 1 THEN RETURN c ELSE RETURN add(c, mult(c, d-1)) END 
END mult; 

PROCEDURE potenz(e, f : CARDINAL) : CARDINAL; 

BEGIN 

IF f = 0 THEN RETURN 1 ELSE RETURN mult(e,potenz(e,f-1)) END 
END potenz; 

VAR n,m : CARDINAL; 
taste : CHAR; 

BEGIN 

REPEAT 

WriteString(”Geben Sie eine nat. Zahl ein (0 = ENDE) : ”); ReadCard(n); 
WriteString(”Noch eine, bitte : ”); ReadCard(m); 

WriteLn; 

WriteCard(n,1); WriteString(” hoch ”); WriteCard(m, 1); 
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WriteString(” ergibt: ”); WriteCard(potenz(n, m), 1); 
WriteLn; 

UNTIL n = 0 
END RekursionsTestö. 


Wir meinen natürlich nicht, daß man so programmieren soll. Dieses Programm hat lediglich 
»didaktischen Wert«, bei größeren Zahlen merkt man wiederum die langsame Abarbeitung. 

Im 2. Beispiel programmieren wir die sogenannte Ackermann-Funktion. Diese ist teuflisch 
rekursiv definiert: 

(1) ack(0,n) = n+1 

(2) ack(m,0) = ack(m-l, 1) 

(3) ack( m,n) = ack(m-l, ack(m,n-l)) 

Der Mathematiker W. Ackermann fand sie bei der Fortsetzung der Folge 
Nachfolger Summe -► Produkt -► Potenz 
Es gilt (was nicht leicht ersichtlich ist): 

(a) ack(l,n) = n + 2 

(b) ack(2,n) = 2n + 3 

(c) ack( 3, n) = 2 n+3 - 3 

Sich mit diesen Sätzen einige Werte zum Testen auszurechnen ist deutlich einfacher als mit der 
eigentlichen Definition. Setzen Sie bitte bei dem Programm keine zu großen Zahlen ein! Die 
Ackermann-Funktion ist berüchtigt für große Rekursionstiefen und enorme Rechenzeiten, 
die sehr schnell mit der Größe der Eingaben wachsen! 

MODÜLE AckermannFunktionDemo; 

FROM InOut IMPORT WriteCard, ReadLCard, WriteString, WriteLn; 

IMPORT Stoppuhr; 

PROCEDURE Ackermann(m,n : LONGCARD) : LONGCARD; 

BEGIN 

IF m = OD THEN RETURN n+lD 

ELSIF n=OD THEN RETURN Ackermann(m-1D,ID) 

ELSE RETURN Ackermann(m-1D,Ackermann(m,n-lD)) END 
END Ackermann; 


VAR i,j 


: LONGCARD; 
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BEGIN 

LOOP 

WriteString(”i ( > 4 = ENDE) : ”); ReadLCard(i); 

IF i > 4D THEN EXIT END; 

WriteString(: ”); ReadLCard(j); 

WriteString(”Ackermann(i,j) = ”); 

Stoppuhr.Start; WriteCard(Ackermann(i, j ) , 1) ; 

WriteString(” Rechenzeit ”); WriteCard(Stoppuhr.Lesen(),1); 
WriteString(” Millisekunden”); WriteLn; 

END 

END AckermannFunktionDemo. 


Die Ackermannfunktion wird oft von Studenten benutzt, um die Absturzsicherheit von 
Großrechenanlagen und die Geduld des Operators zu testen (nach dem Motto: »Wie schnell 
werde ich meine Benutzernummer los?«). 

1.6 Selbstdefinierte Datentypen 

Typen gibt’s... 

Im Gegensatz zu einfacheren Sprachen bietet Modula höchst flexible Gestaltungsmöglichkei¬ 
ten, die in Abschnitt 1.3 besprochenen Standard-Datentypen zu komplexen Strukturen zu 
kombinieren. In welchen Fällen man diese Strukturen einsetzt, wie man sie definiert und 
handhabt, davon soll in diesem Abschnitt die Rede sein. 

Zunächst geht es aber noch ergänzend zu Abschnitt 1.3 um Aufzählungstypen und Unterbe¬ 
reichstypen, die man noch zu den einfachen Typen zählt. Aber auch sie sind schon vom Benut¬ 
zer zu deklarieren. Eine solche Vereinbarung geschieht in einer »Typ-Deklaration«. Sie hat die 
Form 

TYPE 

<Bezeichnerl> = <Typl >; 

<Bezeichner2> = <Typ2 >; 

Die Bezeichner sind damit als Typbezeichner definiert. 

Diese kann man dann in einer Variablen-Deklaration benutzen: 
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VAR 

<Bezeichner-Listel >: <Bezeichnerl>; 

<Bezeichner-Liste2 >: <Bezeichner2 >; 

Die nächsten Abschnitte verschaffen über diese Verwendung Klarheit. 


1.6.1 Aufzählungstypen 

Des öfteren hat man beim Programmieren Daten, die in Form einer Aufzählung Vorkommen, 
also nur mehrere feste Werte annehmen. Beispiele sind Wochentage, Monate, Spielkarten, 
Geschlecht usw. In primitiveren Programmiersprachen wie Basic verwendet man zu ihrer 
Darstellung ganze Zahlen. Das hat den Nachteil, daß man - nehmen wir einmal das Beispiel 
Spielkarten - jeder Spielkarte eine bestimmte Nummer zuordnen muß. Beim Programmieren 
muß man diese Zuordnung (zum Beispiel »As« = 8) dauernd parat haben. Ein Vorteil dieser 
Numerierung ist aber, daß man damit FOR-Schleifen bilden und Kartenwerte erhöhen bzw. 
erniedrigen kann, oder sie als Selektoren einer CASE-Anweisung nutzen kann. 

Modula-2 bietet hier die »Aufzählungstypen«, die diese Vorteile ebenfalls besitzen, ohne daß 
man beim Programmieren die Zuordnung zu einer Nummer im Kopf haben muß. Das macht 
der Compiler. 

Für Aufzählungstypen deklariert man eine Folge von Bezeichnern, die man durch Kommata 
trennt und in runden Klammern einschließt: 



SYNTAX: "Enumeration '(15) 


Beispiele: 

TYPE 

Wochentag = (Montag, Dienstag, Mittwoch, Donnerstag, 
Freitag, Samstag, Sonntag); 

Monat = (Jan, Feh, Mae, Apr, Mai, Jun, 

Jul, Aug, Sep, Okt, Nov, Dez); 

Karte = (Sieben, Acht, Neun, Zehn, Bube, Dame, Koenig, As); 

Eine Variable Tag läßt sich so vom Typ Wochentag deklarieren: 
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VAR Tag: Wochentag; 

und kann dann genau die Werte Montag bis Sonntag annehmen. 

Den Standardtyp boolean kann man sich ebenfalls als Aufzählungstyp denken: 

TYPE BOOLEAN = (FALSE, TRUE); 

Intern wird ein Aufzählungstyp ähnlich einer CARDIN AL-Zahl als Dualzahl dargestellt und 
belegt (je nach Compiler oder Größe) ein oder zwei Byte. Das erste Element eines Aufzäh¬ 
lungstypen wird wie die CARDINAL-Zahl 0 dargestellt, das zweite wie eine l usw. 

Beim Beispiel Wochentag wird also Montag wie 0 und Sonntag als duale 6 abgespeichert. 
Das impliziert gleichzeitig, daß 

Montag < Dienstag < Mittwoch <...< Sonntag 

ist. Der Ausdruck 

Montag < Donnerstag liefert also TRUE. 

Ebenso sind folgende Konstruktionen möglich: 

IF Tag = Montag THEN WriteString("Wochenende vorbei") END; 

IF Tag <= Freitag THEN arbeiten ELSE feiern END; 

Aufzählungstypen gehören zu den skalaren Typen. Deshalb kann man sie auch zur Steuerung 
von FOR-Schleifen einsetzen: 

VAR Tag: Wochentag; 

FOR Tag : = Montag TO Sonntag DO <Anweisungen> END; 

oder, falls man die Reihenfolge der Wochentage nicht im Kopf hat, gleichbedeutend: 

FOR Tag :=MIN(Wochentag) TO MAX(Wochentag) DO <. . . > END; 

Aufzählungstypen sind auch praktisch für CASE-Anweisungen: 

VAR m: Monat; 

OASE m OF 

Januar..April, September..Dezember: 

WriteString("Ein Monat mit ’r’, also Muscheln essen!”) 

ELSE 

WriteString("Besser keine Muscheln essen!”) 


END; 
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Die Standardprozeduren INC und DEC lassen sich ebenfalls verwenden. Nach 

Tag := Montag; 

INC(Tag,3) 

enthält Tag den Wert Donnerstag. 

Achtung: 

Von Montag gibt es keinen Vorgänger. Genauso wenig gibt es zu Sonntag einen Nach¬ 
folger. Also ist nach 
Tag := Montag; 

DEC(Tag); 

die Variable Tag nicht definiert und liefert eventuell einen Laufzeitfehler. 

Notfalls kann man Aufzählungstypen auch auf CARDINAL-Werte abbilden. Dazu gibt es die 
Funktionen ORDund VAL. Erstere wandelt den Wert eines Aufzählungstypen in seine entspre¬ 
chende CARDINAL-Zahl, VAL macht das Gegenteil. 

Wichtig: 

VAL muß dazu aus dem Modul SYSTEM importiert werden. Dazu braucht man in der Im¬ 
portliste PROM SYSTEM IMPORT VAL; 

VAL hat noch eine Besonderheit: es hat als ersten Parameter einen Typ! 

VAL muß schließlich wissen, in welchen Typ es die CARDINAL -Zahl verwandeln soll. 

So liefert 

0RD( Mittwoch) die CARDINAL-Zahl 2 , umgekehrt liefert 
VAL( Wochentag, 2) den Wert Mittwoch. 

Für Werte von Aufzählungstypen gibt es keine Ein- und Ausgabeprozeduren. So etwas wie 
WriteString (Montag) kann nicht funktionieren, schließlich ist Montag kein String, son¬ 
dern ein Bezeichner! 

Aus diesen Beispielen sollte hervorgegangen sein, wie einfach Aufzählungstypen zu hand¬ 
haben sind. Wir werden sie im folgenden öfter benutzen, da sie die Lesbarkeit der Programme 
erhöhen. 


1.6.2 Unterbereichstypen 

Eine weitere Klasse von Datentypen, die der Benutzer selbst definieren kann, sind die »Unter¬ 
bereichstypen«. Ein Unterbereichstyp bildet einen zusammenhängenden Bereich eines ande¬ 
ren skalaren Typs - seines Basistyps - und stellt somit wieder einen skalaren Typ dar. 
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Die Deklaration sieht im einfachsten Fall so aus: 


TYPE <NeuerTyp> = [ <Untergrenze>. . <Obergrenze >]; 
Beispiele: 


TYPE 

Kleinbuchstaben 

Ziffern 

Zweistellig 

Arbeitstag 

Wochenende 


[”a”..”z”]; 

[”0”..”9”]; 

[10..99]; 

[Montag..Freitag]; 
[Samstag..Sonntag]; 


Die beiden ersten Typen Kleinbuchstaben und Ziffern stellen Unterbereichstypen des 
Datentyp CHARdar. Die Typen Arbeitstag und Wochenende sind Unterbereiche des Basis¬ 
typs Wochentag aus dem vorigen Abschnitt. Der dritte Typ Zweistellig ist ein Unterbe¬ 
reich vom Basistyp CARDINAL, da der Compiler die Konstanten 10 und 99 als CARDINAL- 
Konstanten ansieht. Nun hätte man Zweistellig aber auch als Unterbereich des Typs 
INTEGER haben wollen, schließlich sind 10 und 99 auch gültige INTEGER-Konstanten. 
Deshalb ist es auch erlaubt, bei der Definition zusätzlich den Basistypen mit anzugeben: 


TYPE <NeuerTyp> - <BasisTyp>[<Untergrenze>. . <Obergrenze>]; 


Qualldent 2 ConstExpr 27 KH ConstExpr 27 KD- 


SYNTAX: ”Subrange”(16) 

Beispiele: 

Kleinbuchstaben = CHAR[”a”..”z”] 

Zweistelliglnteger = INTEGER [10..99]; 

ZweistelligCardinal = CARDINAL[10. . 99]; 

Ober- und Untergrenze dürfen auch einen konstanten Ausdruck darstellen: 

CONST mitte = 100; 

TYPE Bereich = [mitte - 20 .. mitte + 20]; 

Es sei noch einmal betont, daß ein Unterbereichstyp stets einen zusammenhängenden Teil 
(aufsteigende Folge ohne Lücke, unterer Grenzwert oberer Grenzwert) darstellt. Die Dekla¬ 
ration 


TYPE Vokale = [”A”,”E”,”1”,”0”,”U”]; (*geht nicht! *) 
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ist falsch! Auch gibt es keine REAL-Unterbereichstypen, da REALkein aufzählbarer (skalarer!) 
Typ ist: 

TYPE Intervall = [0.0..1.0]; (*geht nicht! *) 

Wozu braucht man Unterbereichstypen? 

Wie bei Aufzählungstypen gibt es wiederum zwei Gründe: 

a) Erhöhung der Lesbarkeit 

b) Erhöhung der Sicherheit 

Zu a) 

Durch die Einschränkung auf den betreffenden Unterbereich wird dem Leser des Pro¬ 
grammes klar, daß Variablen dieses Unterbereichtyps nur die Werte innerhalb der vorge¬ 
gebenen Grenzen annehmen werden. 

Zu b) 

Zur Laufzeit kann überprüft werden, ob die Variablen eines Unterbereichs nur gültige 
Werte annehmen. Wenn dann das Programm wegen einer unzulässigen Zuweisung ab¬ 
bricht, sollte das dem Programmierer Anlaß zum Nachdenken geben. 


1.6.3 Die Datenstruktur »Feld« (ARRAY) 

Wir kommen nun zum ersten »strukturierten« Datentyp, dem Feld oder ARRAY (engl, array- 
»Feld«). Schauen wir uns das Programm milderLehrer aus dem Abschnitt 1.4.2 an. 

Hier benutzten wir die Variablen notel, note2,..., noteß um die Anzahl der erteilten No¬ 
ten »1« bis »6« abzuspeichern. Für solche Variablen, die vom gleichem Typ sind und mehrfach 
auftreten verwendet man Felder. In unserem Beispiel benötigen wir sechs Variablen für die 
Anzahl der Noten »1« bis »6«: 

VAR note: ARRAY [1..6] OF CARDINAL; 

[1. . 6] ist hier der sogenannte Indextyp, CARDINAL der Basistyp. Damit sind nun die sechs 
Variablen note[l],note[2],note[3],note[4],note[5],note[6] definiert. Auf die i-te 
Note greift man also mit note [ i ] zu. »i« ist dann ein »Index« des Feldes note und note [ i ] 
ist ein »Element« des Feldes. 

Felder lassen sich sehr gut mit FOR-Schleifen bearbeiten. So setzt die nächste Anweisung ein¬ 
fach alle Notenzahlen auf Null: 


F0R i : = 1 TO 6 DO note[i] := 0 END; 
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Wenn wir auch noch die Würfel in einem Feld 

TYPE wuerfel := ARRAY[1..3] OP CARDINAL; 

abspeichern, läßt sich das Programm rasch von 42 auf 28 Zeilen verkürzen. 

MODULE milderLehrerMitArray; 

FROM RandomGen IMPORT Randomize, RandomCard; 

FROM InOut IMPORT WriteCard, WriteReal, WriteLn, WriteString, KeyPressed; 

VAR wuerfel : ARRAY [1..3] OF CARDINAL; 

note : ARRAY [1..6] OF CARDINAL; 

i, anzahl, minimum : CARDINAL; 

BEGIN 

WriteString(”Der milde Lehrer würfelt und würfelt, ”); 

WriteString(”bis Sie eine Taste drücken...”); WriteLn; WriteLn; 
anzahl:=0; 

FOR i := 1 TO 6 DO note[i] := 0 END; 

Randomize(12345); 

REPEAT 

FOR i := 1 TO 3 DO wuerfel[i] := RandomCard(1,6) END; 
minimum := wuerfel[1]; 

FOR i : = 2 TO 3 DO 

IF minimum > wuerfel[i] THEN minimum := wuerfel[i] END 
END; 

INC(note[minimum]); INC(anzahl); 

UNTIL KeyPressed(); 

WriteString(”Anzahl der erwürfelten Noten insgesamt: ”); WriteCard(anzahl,10); 
WriteLn; WriteLn; 

FOR i := 1 TO 6 DO 

WriteReal(FLOAT(note[i]) * 100.0 / FLOAT(anzahl), 6, 2); 

WriteString(”% für Note”); WriteCard(i,2); WriteLn; 

END; 

REPEAT UNTIL KeyPressed() 

END milderLehrerMitArray. 

Mit einem Element eines Feldes kann man also rechnen wie mit einer Variablen des Basistyps. 
Auf Feldern selbst sind keine Operatoren definiert. Will man aber ein Feld in ein anderes ko¬ 
pieren, so braucht man, sofern beide Felder vom gleichem Typ sind, nicht jedes Element ein¬ 
zeln zu kopieren. Statt 
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TYPE feld = ARRAY [1..99] OP CARDINAL; 
VAR a,b: feld; 

i: CARDINAL; 

POR i := 1 TO 99 DO a[i] := b[i] END; 


kann man direkt a: =b; schreiben, wohlgemerkt nur, wenn beide Felder vom gleichen Typ 
sind. 

Allgemein sieht die Deklaration für ein Feld wie folgt aus: 

( — O —i 

— array} -^ 

SYNTAX: ”ArrayType’’(19) 

SimpleType beschreibt einen Indexdatentyp. Jeder Indextyp muß dabei ein Aufzählungstyp, 
ein Unterbereichstyp oder einer der Standardtypen CHAR und B00LEAN sein. Type beschreibt 
den Basistyp des Feldes, also den Datentyp der einzelnen Elemente des Feldes. Im vorstehen¬ 
dem Beispiel also CARDINAL. Folgendes ist also möglich: 

TYPE 

Monat 

Tagzahl 
Geschlecht 
Kleinbuchstaben 

VAR 

TagelmMonat : ARRAY Monat OP Tagzahl; 

Bewohner : ARRAY Geschlecht OP CARDINAL; 

Haeufigkeit : ARRAY Kleinbuchstaben OP REAL; 

Zeichenfeld : ARRAY CHAR OP REAL; 

Falsch wären die Typen: 

ARRAY REAL OP INTEGER; 

ARRAY BITSET OP REAL; 


= (Jan, Peb, Mae, Apr, Mai, Jun, 
Jul, Aug, Sep, Okt, Nov, Dez); 
= [28..31]; 

= (m,w); 

= [”a”..”z”]; 



da weder BITSET noch REAL zulässige Indextypen sind. 
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Mehrdimensionale Felder 

Aus dem Syntaxdiagramm ersieht man , daß auch folgendes möglich ist: 

TYPE Farbe = (schwarz,weiss); 

VAR Schachbrett: ARRAY [1..8],[”A”..”H”] OF Farbe; 

Wir haben hier ein sogenanntes zweidimensionales Feld. Es verkürzt praktisch die Deklara¬ 
tion: 


VAR Schachbrett: ARRAY [1..8] OF ARRAY [”A”..”H”] OF Farbe; 

Ein zweites Beispiel: 

TYPE matrix = [1..3],[1..2] OF REAL; 

VAR m: matrix; 

Hier wird eine Matrix aus 3*2 Zahlen gebildet. Der Zugriff auf eine einzelne Komponente 
kann mit m [ i ] [ j ] oder einfacher mit m [ i, j ] erfolgen. Stellen Sie sich unter diesem zweidi¬ 
mensionalen Feld eine Tabelle bestehend aus 6 Zahlen in 3 Spalten und 2 Zeilen vor. 

Ein Programmbeispiel mit zweidimensionalen Feldern: Bekanntlich gilt für die Binomialkoef¬ 
fizienten des Pascafschen Dreiecks 



Die Koeffizienten können mit dieser Rekursionsformel als zweidimensionales Feld errechnet 
werden: 

MODULE PascalDreieck; 

FROM InOut IMPORT Write, WriteString, WriteCard, WriteLn, Read; 

CONST max « 11; 

VAR 

BinKoeff : ARRAYfO..max],[0..max] OF CARDINAL; 
n,k,1 : CARDINAL; 

taste : CHAR; 

PROCEDURE KoeffizientenBerechnen; 

BEGIN 


FOR n: =0 TO max DO 
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BinKoef f [n, 0] := 1; BinKoef f [n, n] := 1 
END; 

POR n:=1 TO max DO 
POR k:=1 TO n-1 DO 

BinKoeff[n,k] : = BinKoeff[n-l, k-1] + BinKoeff[n-1, k] 
END 
END 

END KoeffizientenBerechnen; 

BEGIN 

WriteString(” Pascalsches Dreieck”); 

KoeffizientenBerechnen; 

POR n := 0 TO max DO 

WriteLn; POR k := 1 TO 33-3*n DO Write(” ”) END; 

POR k : = 0 TO n DO WriteCard(BinKoeff[n, k], 6) END; 

END; 

Read(taste) 

END PascalDreieck. 


In analoger Weise lassen sich mehrdimensionale Matrizen bilden. 

Internes zu Feldern 

Nehmen wir an, wir haben ein Feld 

VAR feld: ARRAY [5..9] OP LONGCARD; 

Eine Adresse im Computer ist nichts an¬ 
deres als die Nummer eines Speicher¬ 
platzes. Bei unserem Feld stimmt die Basis¬ 
adresse des Feldes (also der Speicherplatz, 
an dem das Feld beginnt) mit der Adresse 
von feld[5 ] überein. Wenn der Compu¬ 
ter zum Beispiel auf feld[8] zugreifen 
soll, geht er folgendermaßen vor, um die 
Adresse von feld[8] zu ermitteln: 

1. Berechnung des Abstandes in Elemen¬ 
ten vom kleinstem Element: 

8-5 ergibt 3 

2. Er multipliziert diesen Abstand mit der Speichergröße eines Elementes (hier 4 Byte für 
LONGCARD): 


BA+16 - 
BA+12- 
BA+8 - 
BA+4 ' 
BA = - 


feld[9] 


feld[8] 


feld[7] 


feld[6] 


feld[5] 


}. 4 Bytes 

y 4 Bytes 
j. 4 Bytes 
J. 4 Bytes 
}. 4 Bytes 


Bild 1.18: Speicherung des Feldes 
VAR feld: ARRAY 
[5.. 9] OF LONGCARD 
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3*4 Byte ergibt 12 Byte. 

Damit erhält er den Abstand in Byte. 

3. Er addiert diesen Wert zur Basisadresse des Feldes. Damit erhält er die Adresse des 
Elementes: 

Adresse = Basisadresse + Byteabstand 

Nun, das alles benötigt Zeit und Code. In geschwindigkeitskritischen Fällen kann der ersten 
Schritt vermieden werden, indem man als kleinsten Index 0 vorsieht, in unserem Beispiel also 

VAR feld: ARRAY [0..4] OP LONGCARD; 

deklariert. 

Aus der Darstellung ist ersichtlich, daß sich der Speicherbedarf einer Feldes errechnet zu 
Anzahl der Elemente * Speicherbedarf des Basistyps 
Das Feld 

VAR DreiDimensionen: ARRAY [0. .9], [0. . 9], [0..9] OP LONGCARD; 
belegt also 10*10*10*4 Byte. 

Der Speicher als Feld 

Es wird klar, daß man den Speicher selbst als Feld von Bytes auffassen kann. Daher ist es auch 
möglich, einer bestimmten Variablen einen festen Speicherplatz zuzuordnen. Dies kann unter 
anderem sinnvoll sein, wenn man bestimmte Speicherstellen lesen oder verändern will, in de¬ 
nen das Betriebssystem gewisse Informationen abgelegt hat. Ein Beispiel könnten die System¬ 
variablen des Atari sein. Wir bringen ein Programm dazu im Abschnitt 3.3. Soll die 
CARDINAL-Variable c an der Adresse »FFE« (Hexadezimal) stehen, deklariert man in 
Modula 

VAR c[OPPEH]: CARDINAL; 

Open-ARRAY-Parameter 

Schauen wir uns abschließend die Bestimmung des Minimums der Würfel im Programm 
»MilderLehrerMitArray« an. Man könnte daraus eine schöne Prozedur schreiben. 

Gegeben sei der Typ 

TYPE 

bereich = [5..10]; 

feldtyp = ARRAY bereich OP CARDINAL; 
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und die Prozedur 

PROCEDURE rainimum(feld: feldtyp): CARDINAL; 

VAR 

i : bereich; 
mini : CARDINAL; 

BEGIN 

mini := feld[MIN(bereich)]; 

EOR i := MIN(bereich) + 1 TO MAX(bereich) DO 
IE feld[i] < mini THEN mini := feld[i] END; 
END; 

RETURN mini 
END minimum; 


Es stört hier ein wenig, daß man mit dieser Prozedur nicht beliebige CARDINAL-Felder nach 
dem Minimum durchsuchen kann, sondern nur CARDINAL-Felder vom Typ feldtyp, also mit 
dem Indexbereich [ 5. . 10 ], denn schließlich muß ja der Typ in der Parameterliste angegeben 
werden. Schöner wäre es, eine allgemein nützliche Prozedur zu definieren, die für jedes 
CARDINAL-Feld funktioniert, unabhängig von dem aktuellen Indexbereich. Modula kennt 
hier den »Open-Array«-Typ {open array- »offenes Feld«), einen »JokerFeldtyp«, bei dem in¬ 
nerhalb einer Parameterliste der Indexbereich nicht angegeben werden muß! 

Wir können also im Prozedurkopf schreiben: 

PROCEDURE minimum(feld:ARRAY 0F CARDINAL): CARDINAL; 

Für die Steuerung der FOR-Schleife benötigen wir aber die Indexgrenzen. Wie kommen wir 
jetzt daran? Der kleinste Index wird bei einem offenen Feld stets als 0 (Null) angenommen; 
den größten Index erhält man mit HIGH (feld ). Die Indexgrenzen werden also beim Überge¬ 
ben »transponiert«. Beispielsweise wird ein Feld, das als ARRAY [20.. 25] deklariert ist, als 
ARRAY[0. . 5] übergeben. 

Einem Open-Array-Parameter kann man nur ein Feld beliebiger Größe des gleichen Basistyps 
übergeben. Das folgende Demonstrationsprogramm macht dies klar: 

MODULE OffenesFeldDemo; 

FROM InOut IMPORT Read, WriteCard, WriteString, WriteLn; 

PROCEDURE minimum(feld : ARRAY OF CARDINAL) : CARDINAL; (* »offenes» Feld *) 

VAR min, i :CARDINAL; 
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BEGIN 

min :- feld[0]; 

FOR i := 1 TO HIGH(feld) DO 
IE min > feld[i] THEN min 
END; 

RETURN min 
END minimum; 


» feld[i] END 


VAR 

feldl : ARRAY [5..8] OF CARDINAL; 

feld2 : ARRAY [”A”..”D”] OF CARDINAL; 

feld3 : ARRAY BOOLEAN OF CARDINAL; 

feld4 : ARRAY (rot, gelb, blau) OF CARDINAL; 

feldö : ARRAY [6..6] OF CARDINAL; (* Feld mit nur einem Element *) 

taste : CHAR; 

BEGIN 

feldl[5] : = 5; feldl[6] : = 7; feldl[7] : = 2; feldl[8] := 10; 
feld2[”A”] : = 65; feld2E”B"3 : = 66; feld2[”C”] : = 67; feld2[”D"] : = 68; 
feld3[FALSE] : = 100; feld3[TRUE] := 50; 


feld4[rot] : = 30; feld4[gelb] 
feld5[6] : = 3; 

WriteString("Minimum von feldl 
WriteString(”Minimum von feld2 
WriteString("Minimum von feld3 
WriteString("Minimum von feld4 
WriteString("Minimum von feld5 
Read(taste) 

END OffenesFeldDerao. 


20; feld4[blau] : =10; 




WriteCard(minimum(feldl),2); 
WriteCard(minimum(feld2),2); 
WriteCard(minimum(feld3),2); 
WriteCard(minimum(feld4),2); 


”); WriteCard(minimum(feldö),2); 


WriteLn; 

WriteLn; 

WriteLn; 

WriteLn; 

WriteLn; 


Man sieht also, daß der Open-Array-Parameter eine sehr flexible Programmierung erlaubt. 
Nur mehrdimensionale Arrays lassen sich nicht als Open-Array-Parameter übergeben. 


Es stellt sich die Frage, wie das funktioniert. Woher »kennt« die Prozedur HIGH die obere 
Indexgrenze? 


Bei Open-Array-Parametern wird neben der Basisadresse des Feldes noch der HI GH- Wert (die 
Anzahl der Elemente minus 1) wie ein zusätzlicher Parameter übergeben. Das ist das ganze 
Geheimnis. 


Im Kapitel 2.1 gehen wir tiefer auf die Datenstruktur Feld ein. Erklärtes Ziel dieses Buches ist 
es dabei, möglichst flexible Prozeduren zu schreiben. Die Prozedur minimum mit einem offe¬ 
nen Feldparameter wäre ein erstes einfaches Beispiel hierzu. 
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Strings als Felder 

Zeichenketten oder Strings werden in Modula als ARRAY [0. .max] OF CHAR deklariert. 
Eine Variable dieses Typs kann höchstens max+ 1 Zeichen aufnehmen. Falls nicht alle Zei¬ 
chen belegt sind, wird als Endemarkierung hinter dem letzten gültige Zeichen OC gesetzt. Die 
Länge eines Strings läßt sich demnach mit folgender Prozedur bestimmen: 

PROCEDURE StrLaenge(VAR s :ARRAY OP CHAR) : CARDINAL; 

VAR i : CARDINAL 
BEGIN 
1=0; 

WHILE (s[i] # OC) AND (i<=HIGH(s)) DO INC(i) END 
RETURN i 
END StrLaenge; 


Solche Prozeduren zur Stringbehandlung findet man bereits fertig im Modul Strings , der 
zu jedem Modula-System mitgeliefert wird. 

Es sei nun 

VAR s : ARRAY [0..9] 0F CHAR ; 
statt nun 

s[0]:=”A”; s[l]:=”T”; s[2]:=”A”; s[3]:=”R”; s[4]:=”I”; s[5]:=0C; 

zu setzen, gibt es speziell für Zeichenketten die wesentlich einfachere Möglichkeit, einer Varia¬ 
blen einen konstanten String zuzuweisen: 

s:=”ATARI”; 

leistet dasselbe. Es wird hierbei automatisiert s [5]: =0C gesetzt. Die weiteren Zeichen sind 
dann zufällig belegt. 


1.6.4 Die Datenstruktur »Verbund« (RECORD) 

Es gibt Dinge, die gehören einfach zusammen! Mit der Datenstruktur Feld lassen sich aus¬ 
schließlich Elemente gleichen Typs behandeln. Oft sollen jedoch Daten verschiedenen Typs 
verarbeitet werden, die man unter einem gemeinsamen Oberbegriff zusammenfassen möchte. 

Beispiel hierfür wäre eine Anschrift, bestehend aus Straße, Hausnummer, Postleitzahl (PLZ) 
und Wohnort. In Modula drückt man diesen »Verbund« so aus: 
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TYPE String = ARRAY[0. .29] OF CHAR; 

Adresse = RECORD 

Strasse : String; 

HausNr : CARDINAL; 

Piz : [1000..9999]; 

Wohnort : String 
END; 

Haben wir die Variablen 
VAR 

Anschriftl, Anschrift2: Adresse; 

so bezeichnet Anschriftl. Strasse einen String. Mit Anschriftl wird also auf den ge¬ 
samten Verbund zugegriffen, mit Anschriftl. <Bezeichner> auf eine einzelne »Kompo¬ 
nente« (in der Literatur auch mit »Feld« bezeichnet; wir unterlassen das, da eine Begriffsver¬ 
wechselung mit ARRAY entstehen könnte). 

Folgende Zuweisungen sind also korrekt: 

Anschriftl.Strasse := "Hohe Gasse”; 

Anschriftl. HausNr := 315; 

Anschriftl. Piz := 5600; 

Anschriftl.Wohnort := ”Wuppertal 1”; 

Anschriftl. Strasse[1] := ”ö”; 

Anschrift2 : = Anschriftl; 

Aus dem letztem Beispiel ist ersichtlich, daß man Verbünde gleichen Typs wie Felder einander 
zuweisen kann. 

Faßt man die Unterschiede von Feldern und Verbunden zusammen, so ergibt sich: 

• Felder sind Zusammenfassungen von Daten gleichen Typs, Verbünde sind Zusammenfas¬ 
sungen von Daten verschiedenen Typs. 

• Auf eine einzelne Feldkomponente kann man mit einem Ausdruck zugreifen (z.B. 
f eld [ 5 * 3+i ]), bei einem Record wird die Komponente durch ihren Bezeichner mit einem 
vorangestellten Punkt selektiert (Anschriftl. Strasse). 

Internes Datenformat 

Die Abspeicherung eines Verbundes erfolgt komponentenweise nacheinander. Also errechnet 
sich der gesamte Speicherplatzbedarf eines Verbundes als Summe seiner Komponenten. Der 
Datentyp Adresse belegt demnach 
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30 Byte (30*1 Byte für CHAR) 

+ 2 Byte (CARDINAL) 

+ 2 Byte (Unterbereichstyp von CARDINAL) 
+ 30 Byte (30*1 Byte für CHAR) 


= 64 Byte für den Datentyp Adresse 

Anmerkung: 

In der Praxis kann es Vorkommen, daß der Verbund etwas mehr Speicherplatz belegt als 
die Summe seiner Komponenten. Das liegt daran, daß aus technischen Gründen »Füll¬ 
bytes« eingeschoben werden müssen, wenn eine Komponente eine ungerade Zahl von By¬ 
tes belegt. Der 68000-Prozessor liebt nun mal gerade Adressen. 

Die WITH-Anweisung 

Im obigen Beispiel weisen wir zu: 

Anschriftl.Strasse := 

Anschriftl. HausNr := 

Anschriftl. Piz := 

Anschriftl. Wohnort := ...; 

Diese sperrige Konstruktion läßt sich mit der WITH-Anweisung vereinfachen zu 

WITH Anschriftl DO 
Strasse : = . . . ; 

HausNr : = . . . ; 

Piz := ... ; 

Wohnort : = ... 

END; 

Innerhalb der WITH-Anweisung sind Strasse, HausNr, Piz und Wohnort bekannt. Die 
WITH-Anweisung spart also Schreibarbeit. Außerdem kann sie effektiver sein, wenn in der 
WITH-Klausel (der Ausdruck zwischen WITH und DO ) eine indizierte Feld variable ist, da hier 
der Index nur einmal ausgerechnet zu werden braucht. WITH-Anweisungen dürfen natürlich 
auch geschachtelt werden. 
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Ein komplexes Beispiel 

Selbstverständlich können die Komponenten wiederum Verbünde (oder auch Felder) sein. 
Die folgende Deklaration zeigt ein komplexes Beispiel: 

CONST 

maxZeichen = 29; 
maxBelegung = 1000; 


= ARRAY [0..maxZeichen] OE CHAR; 
RECORD 

[1. .31]; 

[ 1 . . 12 ]; 

CARDINAL; 


TYPE String 
Datum * 

Tag 
Monat 
Jahr 
END; 

Adresse = RECORD 

Strasse 
HausNr 
Piz 

Wohnort 
END; 

NameTyp = RECORD Vorname, Nachname: String END; 
Mitarbeiter = RECORD 
Name 

Anschrift 
Geburtstag 
Konfession 
Gehalt 
END; 


String; 
CARDINAL; 
[1000..9999]; 
String 


NameTyp 

Adresse; 

Datum; 

(ev,rk,so); 
Real 


VAR Belegschaft: ARRAY [0..maxBelegung] OE Mitarbeiter; 


Der hierarchische Aufbau des Feldes Belegschaft läßt sich in einem Datenstrukturbaum 
graphisch darstellen: 
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Bild 1.19: Datenstruktur-Baum für die Variable >Belegschaft< 

An den »Blättern« des Baumen, also dort unten, wo es nicht mehr weitergeht, sind die Daten¬ 
typen elementar. Es bezeichnet 

Belegschaft: 

Die gesamte Belegschaft eines Betriebes 

Typ: ARRAY [0..maxBelegung] OP Mitarbeiter 

Belegschaft [5]: 

Den 5. Mitarbeiter 

Typ: Mitarbeiter (Verbund) 

Belegschaft[5].Name: 
seinen Namen 
Typ: NameTyp (Verbund) 

Belegschaft[5].Name.Nachname: 
seinen Nachnamen 

Typ: String (= ARRAY [0..29] 0F CHAR) 

Belegschaft[5].Name.Nachname[0]: 

Den ersten Buchstaben seines Nachnamens 
Typ: CHAR 

Ein Geburtsdatum weist man dem siebten Mitarbeiter wie folgt zu: 
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WITH Belegschaft[7].Geburtstag DO 
Tag : ss 24; Monat : = 12; Jahr : = 0 
END; 


Man erkennt an diesen Beispielen, daß die Datenstruktur Verbund fundamental für Daten¬ 
verwaltungsaufgaben ist. Daher werden wir im Abschnitt über Dateien 2.3 darauf zurück¬ 
kommen. Darüber hinaus gibt es in Modula Möglichkeiten, komplexe Datenstrukturen und 
»Abstrakte Datentypen« zu formulieren; auch hierauf gehen wir im gesamten Kapitel 2 ein. 

Die Syntax von Verbunden und Varianten Verbunden 

Vergleichen Sie die folgenden Syntaxdiagramme mit unseren Beispielen! 


RECORD y 



i 

Q 

1^._ 


\ 

r — 




J 

( w 

FieldList 2 i 

j 




GEbH 


SYNTAX: ”RecordTyp”(20) 



SYNTAX: ”FieldList”(21) 


\ > 

Ident ! 



f * 

^ _ 

> 


GH Qualldent~ 2 ~] h<°EH 


<D- 


Variant 23 


►(else)- 




\ 


FieldList 2 i 

/ 




y-^END}—» 


S YNTAX: ”VariantFieldList ”(22) 
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f 

V » /"* 

> 



CaseLabelList 24 


i j 

FieldList 2 i 

j 






4 * 





) 



SYNTAX: ”Variant”(23) 


Es dürfte auffallen, daß es da noch einen längeren C ASE-Zweig gibt, den wir noch nicht bespro¬ 
chen haben. Dies ist wirklich eine interessante Angelegenheit, denn damit ist es möglich, zwei 
unterschiedlichen Variablen den gleichen Platz im Speicher einzuräumen! Diese Struktur 
heißt Varianter Verbund«. Beispiel: 

MODULE VarianterRecordDerno; 

PROM InOut IMPORT WriteCard, Writelnt, WriteString, WriteLn, Read; 

VAR taste: CHAR; 

VarRec: RECORD 

OASE Selektor: BOOLEAN OP 
PALSE: i:INTEGER | 

TRUE: c:CARDINAL 

END 
END; 

BEGIN 

VarRec.Selektor := PALSE; VarRec.i := -1; 

WriteLn; WriteString(”Wert als INTEGER: ”); 

VarRec.Selektor := PALSE; Writelnt(VarRec. i, 1); 

WriteLn; WriteString("Wert als CARDINAL: ”); 

VarRec.Selektor := TRUE; WriteCard(VarRec. c, 1); 

Read(taste) 

END VarianterRecordDerno. 


Das Programm gibt aus: 

Wert als INTEGER: -1 
Wert als CARDINAL: 65535 
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Klar, wir belegen in der ersten Programmzeile VarRec. i mit -1. Intern: 

11111111 11111111 (Dual) 

Nun hat VarRec. c aber denselben Speicherplatz. Also wird bei VarRec. c diese Zahl als 
Kardinalzahl interpretiert. Die CARDINAL-Zahl mit diesem Bitmuster entspricht aber 65535. 

Die Variable Selektor gibt im allgemeinen an, welche »Variante« des Speicherplatzes (hier: 
i oder c ) gerade gültig ist. Man kann den Selektor auch weglassen, damit erspart man sich 
das Umschalten auf TRUE bzw. FALSE beim Zugriff auf die Varianten. 

VAR VarRec: RECORD 

CASE : BOOLEAN 0F 
FALSE: i: INTEGER | 

TRUE: c:CARDINAL 

END; 

END; 

In einem Record können natürlich Variante und nichtvariante Teile Vorkommen. Zum Bei¬ 
spiel: 

Type AtomKern = RECORD 

Name : ARRAY[0..19] OF CHAR; 

Symbol : ARRAY [0..1] OF CHAR; 

Protonenzahl, 

Neutronenzahl : CARDINAL; 

CASE radioaktiv : BOOLEAN OF 
TRUE: Halbwertszeit: REAL 
END 
END; 

VAR Elemente: ARRAY [1..1000] OF Atom; 

WITH Elemente[1] DO 

Name : = ”Wasserstoff”; 

Symbol := ”H”; 

Protonenzahl := 1; 

Neutronenzahl := 0; 
radioaktiv := FALSE 
END; 

WITH Elemente[800] DO 
Name := ”Uran 238” 

Symbol := ”U”; 
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Protonenzahl : = 92; 

Neutronenzahl : = 146; 
radioaktiv := TRUE; 

Halbwertszeit := 4.67E9 (* Jahre *) 

END; 


1.6.5 Die Datenstruktur »Menge« (SET) 

Wir haben bereits den Standard-Datentyp BITSET kennengelernt. Er beschreibt die Teil¬ 
mengen der Menge {0,1,..., 15}. Der Datentyp SET (engl, set = »Menge«) verallgemeinert die¬ 
ses Konzept. Ein SET-Typ wird mit 

SET OE <BasisTyp> 

angegeben. 

Der Basistyp ist dabei entweder ein Aufzählungstyp oder ein Unterbereichstyp der Form 
[ 0 . . <Obergrenze>] . Der Basistyp darf nur eine bestimmte Anzahl von Elementen umfas¬ 
sen, bei den Compilern für den Atari meist 16; Megamax-Modula gestattet hier 65 536 Ele¬ 
mente. Da aber der Compiler für jedes Element ein Bit benötigt, gilt für den benötigten Spei¬ 
cherplatz: 

SET 0F [0. . n] belegt n+1 Bits (also (n+7) DIV 8 Byte,da auf ganze Byte aufgerundet wird). 

Eine Menge mit 16 Elementen belegt 2 Byte, das ist standardmäßig das Maximum. Die von 
Pascal-Programmierern so beliebte Menge SET0FCHAR ist deshalb bei einigen Modula- 
Compilern nicht machbar. Megamax erlaubt hingegen: 

SET 0F CHAR belegt 32 Byte (256 Bit) 

SET OF [0. .65535] belegt 8 Kbyte = 8192 Byte 

SET OF BOOLEAN belegt 1 Byte (bei Megamax) 

Mit Mengen kann man genauso operieren wie mit dem Typ BITSET. Hierzu das folgende Pro¬ 
gramm: 

MODULE MengenDemo; 

FROM InOut IMPORT Read, WriteCard, WriteString, Write, WriteLn; 

Bereich = [0..9]; 

ZiffernMenge = SET OF Bereich; 


TYPE 
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PROCEDURE SchreibMenge(m : ZiffernMenge); 
VAR i : Bereich; 

korama : BOOLEAN; 

BEGIN 

Write(”; 
komma : = PALSE; 

EOR i:=0 TO 9 DO 
IE i IN m THEN 

IF komma THEN Write(”,”) END; 
WriteCard(i,1); komma := TRUE 
END; 

END; 

Write(”}”) 

END SchreibMenge; 

CONST ml = ZiffernMenge{l,2,3,4,5,6}; 
m2 = ZiffernMenge{4,5,6,7,8,9}; 


VAR taste : CHAR; 


BEGIN 

WriteString(”Programm zur Demonstration von Mengen”); 


WriteString(”Menge ml lautet ”); 
WriteString(”Menge m2 lautet ”); 
WriteString(”Durchschnitt ml*m2 = ”); 
WriteString("Vereinigung ml+m2 = ”); 
WriteString(”Differenz ml-m2 = ”); 
WriteString(”Differenz m2-ml = ”); 
WriteString(”sym. Diff. ml/m2 = ”); 
Read(taste) 

END MengenDemo. 


SchreibMenge(ml); 
SchreibMenge(m2); 
SchreibMenge(ml*m2); 
SchreibMenge(ml+m2); 
SchreibMenge(ml-m2); 
SchreibMenge(m2-ml); 
SchreibMenge(ml/m2); 


WriteLn; WriteLn; 
WriteLn; 

WriteLn; 

WriteLn; 

WriteLn; 

WriteLn; 

WriteLn; 

WriteLn; 


Dies liefert folgende Ausgabe: 

Programm zur Demonstration von Mengen 
Menge ml lautet {1,2,3,4,5,6) 

Menge m2 lautet {4,5,6,7,8,9} 

Durchschnitt ml*m2 = {4,5,6} 

Vereinigung ml+m2 = {1,2,3,4,5,6,7,8,9} 

Differenz ml-m2 = {1,2,3} 

Differenz m2-ml = {7,8,9} 

symm. Diff. ml/m2 = {1,2,3,7,8,9} 
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Es gibt auch Mengenkonstanten. Dabei muß der Mengentyp mit angegeben werden: 

<Mengentyp>{<Elementeliste>) 

Diese können dann so verwendet werden: 

TYPE ZiffernMenge = SET OF [1..9]; 

CONST mk = ZiffernMenge{1,2,6}; 

leer = ZiffernMenge{}; (* Angabe einer leeren Menge *) 

Auch wenn die Menüs, bei denen man die Anfangsbuchstaben der Menüpunkte eintippen 
muß, beim Atari etwas aus der Mode gekommen sind, wollen wir einfache Menütechnik zur 
Demonstration von Mengen zeigen. Die Handhabung von den Atari-typischen Pull-down- 
Menüs wird in Abschnitt 4.7 gezeigt. Wichtig am Beispiel-Programm ist die Prozedur 
LiesZeichen. Man kann hier solange ohne Bildschirmecho Zeichen eintippen, bis ein gülti¬ 
ges Zeichen (festgelegt durch okMenge) eingegeben wird. Damit auch auf Kleinbuchstaben in 
Meldung reagiert wird, wird die Funktion CAP benutzt, allerdings nur dann, wenn ausdrück¬ 
lich Großbuchstaben erwünscht sind (also die OK-Menge nur aus Großbuchstaben besteht). 
Statt der Prozedur Meldung werden in einem realistischen Programm nun andere Prozedu¬ 
ren stehen. 


MODULE MenueDemo; 

FROM InOut IMPORT BusyRead, Write, WriteString, GotoXY; 

TYPE ZeichenMenge = SET OF CHAR;(* Akzeptiert nicht jeder Modula-Compiler*) 

PROCEDURE LiesZeichen(okMenge : ZeichenMenge) : CHAR; 

VAR ch : CHAR; 

BEGIN 

REPEAT 

REPEAT BusyRead(ch) UNTIL ch # OC; (* Einlesen ohne Bildschirmecho *) 

IF okMenge * ZeichenMenge{”a”..”z”} = ZeichenMenge{} THEN ch: =CAP(ch) END; 
IF NOT (ch IN okMenge) THEN Write(7C) ELSE Write(ch) END; 

UNTIL ch IN okMenge; 

RETURN ch 
END LiesZeichen; 

PROCEDURE Meldung(art : CHAR); 

BEGIN 

GotoXY(10,18); 

WriteString(”Sie wählten den Menüpunkt ”); 
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CASE art OE 

»A» : WriteString(»Arbeiten»); 

”R” : WriteString(»Rechnen ”); 

»D» : WriteString(»Drucken »); 

”E” : WriteString(»Ende »); 

END; 

END Meldung; 

PROCEDURE Menue; 

VAR wähl : CHAR; 

BEGIN 

GotoXY(10,10); WriteString(»A rbeiten”); 

GotoXY(10,11); WriteString(»R echnen»); 

GotoXY(10,12); WriteString(»D rucken»); 

GotoXY(10,13); WriteString(”E nde»); 

GotoXY(10,15); WriteString(»Ihre Wahl: »); 

REPEAT 

GotoXY(21,15); 

wähl : =LiesZeichen(ZeichenMenge{”A”,»R»,»D»,»E»)); 
Meldung(wähl); 

UNTIL wähl = »E» 

END Menue; 

BEGIN 

Menue 

END MenueDemo. 


Wir werden die Prozedur LiesZeichen noch einmal aufgreifen bei der Besprechung von 
Strings (Abschnitt 1.7.3). Dort wird eine »mengenfreie« Version geboten. 


1.6.6 Die Datenstruktur »Zeiger« (POINTER) 

Bei unserer Spracheinführung haben wir des öfteren die Frage beantwortet, wie gewisse Varia¬ 
blen intern dargestellt werden. Schauen wir uns nun einmal den gesamten Speicher des Rech¬ 
ners zur Laufzeit eines Programms an. 
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Der Speicher zur Programm-Laufzeit 

Im großen und ganzen sieht das bei allen Compilern ähn¬ 
lich aus: 

Die Pfeile deuten jeweils an, in welcher Richtung die Spei¬ 
cherbereiche gefüllt werden. 

Die Adressen Al und A5 sind vom Computersystem 
vorgegeben. Der Speicherbedarf der globalen Variablen 
wird durch die Variablendeklaration eines Programmes 
festgelegt. Der Compiler reserviert also hierfür den ent¬ 
sprechenden Speicherplatz, die Adresse A4 ist ihm also 
bekannt. Ebenso ist die Adresse A2 durch den Compiler 
nach Beendigung des Übersetzungsvorganges gegeben. 

Des weiteren wird beim Programm-Ablauf beim Eintritt 
in eine Prozedur (bei ihrer »Inkarnation«) Speicherplatz 
für die Rücksprungadressen, die Parameter und die loka¬ 
len Variablen benötigt, der nach Verlassen der Prozedur 
wieder freigegeben wird. Dafür wird ein bestimmter Spei¬ 
cherbereich vorgesehen: der Stack (engl, stack = 
»Stapel«). Es bleibt also noch ein großer freier Bereich, 
der sogenannte Heap (engl, heap = »Halde«). 

In diesem Bereich kann der Modula-Programmierer auch 
Daten ablegen. Während aber die Verwaltung globaler 
und lokaler Variablen automatisch abläuft (das System 
»merkt« sich, wo es etwas hingeschrieben hat), muß sich 
der Programmierer bei Benutzung des Heap auch etwas 
mit der Speicherverwaltung auseinandersetzen. Außer¬ 
dem muß er wissen, an welchem Speicherplatz (Adresse) 
welche Daten abgelegt wurden. 


A5 


A4 


A3 


A2 


AI 


0 


Platz für globale Variablen 


Stack 

(für lokale Variablen usw.) 


Heap 


Code 


vom Sytem benutzt 


Bild 1.20: Speicheraufteilung 
zur Laufzeit eines Programms 


Dies hört sich kompliziert an, ist es aber nicht, weil Modu- 
la das sogenannte Pointer-Konzept (engl, pointer 
= »Zeiger«) unterstützt. Zeiger sind nichts anderes als 

Adressen, mit denen die Speicherplätze für unsere Variablen erreicht werden können. Zum 
Ablegen und Löschen stellt Modula die Prozedur ALLOCATE und DEALLOCATE aus dem 
Standardmodul Storagezu Verfügung. Doch bevor wir auf Einzelheiten gehen, sei die Frage 
erlaubt: 
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Wozu dynamische Speicherverwaltung? 

Betrachtet man zum Beispiel die Datenstruktur 
feld: ARRAY [0..999] OP INTEGER; 

so werden hierfür 1000*2 Byte reserviert. Der Nachteil eines Feldes liegt darin, daß die An¬ 
zahl der Elemente im voraus festgelegt werden muß. Dies kann zu Speicherplatzverschwen¬ 
dung führen, wenn in einem Programm nicht das gesamte Feld belegt wird. Gravierender ist es 
jedoch, wenn während der Programmausführung, zum Beispiel durch Tastatureingabe, mehr 
Daten erzeugt werden, als vom Programmierer vorgesehen waren. 

Abhilfe schafft hier das Zeigerkonzept. Man spricht von einer dynamischen Datenstruktur, 
da die Anzahl der zu belegenden Bytes erst während des Programmablaufs nach Bedarf reser¬ 
viert wird. Bereits belegter, aber nicht weiter benötigter Speicherplatz kann wieder für neue 
Variablen freigegeben werden. 

Der Umgang mit Zeigern 

In Modula sind Zeiger immer an bestimmte Datentypen gebunden. Ein Pointertyp lautet 
»POINTER TO <Basistyp>«. Eine Typdeklaration lautet daher: 

TYPE <PointerBezeiohner> - POINTER TO <Basistyp>; 

Ist nun die Variable 

VAR p: <PointerBezeichner >; 

gegeben, so »zeigt« p auf eine Variable vom Typ <BasisTyp >, das heißt, p enthält die Adresse 
einer Variablen vom Typ <BasisTyp>. Da p eine Adresse enthält, also beim Atari einen 32- 
Bit-Wert, beansprucht p nur 4 Byte, p selbst ist nun eine Variable (global oder lokal) und 
wird daher nicht auf dem Heap abgespeichert. Die Prozedur Storage. ALL0CATE reserviert 
nun Platz für eine Variable vom Typ <BasisTyp>auf dem Heap. Dies ist die Variable, auf die p 
»zeigt«, das heißt, deren Adresse p enthält. 

Diese Variable auf dem Heap heißt p~ (lies »p-ceil«, etwa dt. »p-Dach«; die abgewandelte 
deutsche Aussprache »p-Ziel« ist noch anschaulicher). 

Beispiel: 

MODULE Zeigerl; 

PROM Storage IMPORT ALLOCATE; 


VAR p: POINTER TO REAL; 
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BEGIN 

ALLOCATE(p, SIZE(p~)); 
p Ä := 1.0; 

END Zeigerl. 


Hier wird die Zahl 1.0 auf dem Heap abgelegt. 
ALLOCATE braucht dazu die Größe des Spei¬ 
cherbereiches, die für die betreffende Variable, 
die auf dem Heap reserviert werden soll. Man 
erhält diesen Wert mit SIZE (p ~). 

Der Pfeil deutet an, daß p auf p~ zeigt. An die 
Variable p~ (also an unserem Wert 1.0) kommt 
man nur über p heran. Zum Beispiel schreibt 

WriteReal (p~, 3,1); 

den Inhalt des Speichers, auf den p zeigt. Man 
erkennt, daß pro abgespeichertem Datum ein 
Zeiger existieren muß, um an die Daten heran¬ 
zukommen. Das macht das ganze Verfahren 
vorläufig ineffizient. Von Dynamik kann auch 
keine Rede sein, da die Anzahl der Pointer wie¬ 
derum vor der Laufzeit bekannt sein müßte. Der 
Trick besteht nun darin, daß man auch die Zei¬ 
ger selbst auf dem Heap ablegt! Lediglich ein¬ 
zelne Zeiger, zum Beispiel auf das erste oder letz¬ 
te abgelegte Element, werden separat vorreser¬ 
viert. Dieses Verfahren erreicht man durch den 
RECORD-Typ: 

TYPE Knoten = RECORD 

info: <IrgendeinTyp>; 
naechster: POINTER TO Knoten; 
END; 


Hierbei enthält info die eigentlich abzuspei¬ 
chernde Information und naechster die 
Adresse, an der die nächste (aus Information 
und Zeiger bestehende) zu finden ist. 


A5 


A4 


A3 


A2 


AI 
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Platz für globale Variablen 


P 


Stack 

(für lokale Variablen usw.) 


Heap 


p~ =1.0 


Code 


vom Sytem benutzt 


Bild 1.21: Speicher mit p und p ~ 
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Das nachfolgende Programm erzeugt eine »verkettete Liste« der abgebildeten Form. 

Wir benötigen nur den globalen Zeiger oben 
um beliebig viele über die Tastatur herein¬ 
kommende CARDINAL-Zahlen abzuspei¬ 
chern. Um die gesamte Liste wieder auszule¬ 
sen, hangelt man sich von Anfang über die 
einzelnen Zeiger hinunter bis zum Ende. Das 
Ende ist dadurch markiert, daß das zuerst 
abgelegte Element, welches keinen Nachfol¬ 
ger hat, auf NIL zeigt. NIL ist ein vordefin¬ 
ierter Zeiger ins »Nichts«. Er ist zu allen Zei¬ 
gertypen kompatibel und wird intern meist 
als Adresse 0 oder -l dargestellt. Daher ist 
der Zugriff 

p : = NIL; 

P~ : = 

nicht erlaubt, man würde damit einen Spei¬ 
cherbereich überschreiben wollen, der eigent¬ 
lich für andere Zwecke gedacht war. Das 
nächste Programmstück zeigt die typische 
Schleifenkonstruktion. 

p := Anfang 
WHILE p # NIL DO 

<p~.info bearbeiten> 
p : = p A . naechster 
END 

Bei Feldern wäre das zu vergleichen mit einer Anweisung der Form: 

F0R i := 0 TO max DO <feld[i] bearbeiten> END; 

MODULE ZeigerDerao; 

FROM Storage IMPORT ALL0CATE; 

FROM InOut IMPORT ReadCard, Read, WriteString, WriteLn; WriteCard; 
TYPE 

Zeiger = POINTER TO Knoten;(* Vorwärtsreferenz bei Zeiger erlaubt! *) 
Knoten = RECORD 



Bild 1.22: Verkettete Liste auf dem Heap 


zahl 


: CARDINAL; 


(* zu speichernde Information *) 
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naechster : Zeiger (* Zeiger für die Verkettung *) 

END; 

VAR 

Anfang, p : Zeiger; 
taste : CHAR; 

BEGIN 

WriteString(”Geben Sie fortlaufend nat. Zahlen ein (0 = Ende)”); WriteLn; 
Anfang:=NIL; 

REPEAT (* Liste einiesen *) 

ALLOCATE(p,SIZE(p"));(* Speicherbereich für einen Knoten reservieren *) 
ReadCard(p".zahl); 
p~.naechster := Anfang; 

Anfang := p 

ÜNTIL Anfang".zahl = 0; 

WriteLn; (* Liste auslesen *) 

p := Anfang; 

WHILE p # NIL DO 

WriteCard(p".zahl,1); WriteLn; 
p := p".naechster 
END; 

Read(taste) 

END ZeigerDemo. 


Schauen Sie sich genau an, wie die Liste aufgebaut wird und wie sie anschließend ausgelesen 

wird. Folgendes dürfte auffallen: 

1. Die Zahlen werden in umgekehrter Reihenfolge ausgegeben wie sie eingelesen wurden. 

2. In der Typdeklaration taucht der Typ Knoten in der Zeigerdeklaration auf, bevor er 
deklariert wird (das geschieht erst in der nächsten Zeile). Eine solche »Vorwärtsreferenz« 
ist bei Zeigern erlaubt. 

3. Der Speicher wird nach der Ausgabe nicht wieder freigegeben. 

4. Es können beliebig viele (jedenfalls so viele, wie auf den Heap passen) Zahlen gespeichert 
werden. 

5. Man kommt nicht auf Anhieb an eine bestimmte Zahl heran. Möchte man zum Beispiel die 
dritte Zahl lesen, muß man sich erst durch die beiden ersten Elemente »durchhangeln«. 
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Zu 1: 

Wir haben hier eine Datenstruktur, die im allgemeinen als Keller oder Stapel bezeichnet wird. 
Was man zuletzt »obendrauf« legt, muß man auch zuerst wieder abholen. Es gibt andere 
Strukturen wo der erste gespeicherte Wert auch wieder am Beginn geholt wird. Näheres dazu 
später im Abschnitt 2.2.2. 

Zu 3: 

Bei unserem kleinen Beispiel ist das nicht weiter tragisch, da der angeforderte Speicher nach 
Beendigung des Programms automatisch freigegeben wird. Wird aber innerhalb eines Pro¬ 
grammes ständig neuer Speicher benötigt, so gibt man nicht mehr benötigten Speicher mit der 
Prozedur DEALLOCATE wieder frei. 

Zu 4: 

Genau das war ja das Ziel! Unser eingangs geschildertes Problem der unbekannten In¬ 
dexgröße für ein Feld ist damit gelöst. Wenn man nicht vorher weiß, wieviele Feldelemente 
sich anhäufen, speichert man sie als Liste auf dem Heap. 

Zu 5: 

Das ist ein Nachteil. Bei einem Feld kommt man über den Index sofort an jedes Element. 
Listen kann man im Grunde nur der Reihe nach lesen. 

Wenn Sie zum erstenmal von Zeigern gehört haben, bleiben sicherlich noch eine Menge Fra¬ 
gen, die nicht durch ein Beispielprogramm zu klären sind. Wir bringen hier aber keine weiteren 
Beispiele, da im gesamten Kapitel 2 mit dynamischen Datenstrukturen gearbeitet wird und 
dort systematisch alle Kunstgriffe vermittelt werden. 

Dabei hat man es mit folgenden komplexen Strukturen zu tun: 



Bild 1.23: Verkettete lineare Liste 
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Bild 1.24: Ringliste 



Bild 1.25: Doppelt verkettete Liste 



Bild 1.26: Binärer Baum 
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NIL NIL 




Daten 






N I L 


Bild 1.27: Lineare Liste von linearen Listen 
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Erlaubte Operationen mit Pointern 
Zuweisung 

Die Zuweisung ist nur zwischen Pointen mit gleichem Basistyp erlaubt: 
p : = q 

ist also falsch, falls p vom Typ POINTER TO Typl und q vom Typ POINTER TO Typ2 ist. 

Vergleich 

Zwischen Pointern gleichen Typs gibt es nur 
p = q (Gleichheit) und 
p # q (Ungleichheit). 

Andere Vergleichsoperatoren sind für Zeiger nicht definiert. 

Berechnungen 

Verändern des Wertes eines Pointers geschieht im allgemeinen durch Zuweisung. Wichtig sind 
eigentlich nur drei Fälle: 
p : = NIL; Zuweisen von NIL 

p : = q; Zuweisen eines anderen Pointers 

allocate( p, p~) ; »Zuweisung« von Speicherplatz 

Zuweisungen können natürlich auch über Funktion oder Parameterlisten erfolgen; damit ver¬ 
lagert sich die Zuweisung in die Prozedur. Andere Operationen sind nicht erlaubt, allerdings 
gestatten manche Compiler INC und DEC auf Pointern. Unkontrolliert angewendet führt das 
möglicherweise zu einem Programmabsturz. 

Im Modul SYSTEM gibt es einen »Joker-Pointer-Typ« ADDRESS. Dieser »Pointer« kann jedem 
Zeigertyp zugewiesen werden und umgekehrt; außerdem ist er mit LONGCARD kompatibel. 
Nach 

EROM SYSTEM IMPORT ADDRESS; 

VAR al,a2: ADDRESS; 

pl: POINTER TO <irgend ein Typ> ; 
p2: POINTER TO <noch ein Typ> ; 

geht also 

al := pl; 

p2 := al; (* Jetzt ist pl = p2 *) 
al := 123L * a2; 

INC(a2); 

DEC(al,4); 
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Über den Sinn insbesondere der letzten drei Anweisungen läßt sich streiten. Wir zeigen aller¬ 
dings in Kapitel 2.1 eine brauchbare Anwendung zur »POINTER-Arithmetik«. 

Ein Selbsttest 

Dies ist sicherlich neben der Rekursion der schwierigste Abschnitt gewesen. Deshalb sei ein 
kleiner Test gestattet. 

Gegeben sei folgende verzeigerte Liste von »Knoten«. Es gilt die Deklaration: 

TYPE Knoten = RECORD 

info: CHAR; 

naechster: POINTER TO Knoten 
END; 



Bild 1.28: Eine lineare Liste mit den Inhalten »A«, »B«, »C«, »D«, »E«. 

Frage: 

Worin besteht der Unterschied in den Wertzuweisungen 

a) p : = q; 

b) p~.ch := q~.ch; 

c) p* : = q-; 

Lösung: 
p : = q 

bewirkt, daß der Zeiger p auf das selbe Element wie q zeigt, p zeigt jetzt auf den Knoten mit 
dem Inhalt ”D”. 
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Bild 1.29: Liste nach p:=q 

Nach p Ä . ch : = q A . ch 

wird ”B” durch ”D” überschrieben. 



Bild 1.30: Liste nach pl.ch:=ql.ch 

Nach p A : = q~ wird der gesamte Knoten auf den p zeigt, überschrieben: 



Bild 1.31: Liste nach pl:=ql 
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Die Knoten mit der »Information« ”C” und ”D” sind nun aus der Liste »ausgekettet«. ”D” 
ist nur noch über q zugänglich, ”C” überhaupt nicht mehr! Die folgende Leseschleife liefert 
nur »ADE«. 

p :« anfang; 

WHILE p#NIL DO 
Write(p“.ch); 
p := p~.naechster 
END; 

An diesen Beispielen erkennt man, daß man mit Pointern sehr umsichtig arbeiten sollte! 


1.6.7 Der Datentyp »PROZEDUR« 


Schauen wir uns das Beispiel der Nullstellenbestimmung aus (1.5.4) an! 

Hier wird eine Funktion f aufgerufen, die zuvor durch eine Funktionsprozedur deklariert 
wurde. Wenn man aber damit in einem Modul die Nullstellen mehrerer Funktionen bestim¬ 
men möchte, so ist dies nicht möglich, da die Prozedur Nullstelle mit der »globalen« 
Funktion f operiert. Man möchte gerne eine Funktion in der Parameterliste von Null¬ 
stelle mit übergeben können. 

In Modula ist es möglich, beliebige Prozeduren - die selber wieder beliebige Parameterlisten 
haben können - als Parameter in einer anderen Prozedur zu verwenden! Hierzu dient der Da¬ 
tentyp PROCEDURE. Die Typdeklaration für die Funktion 

PROCEDURE f(x:REAL): REAL 

lautet: 


TYPE reelleEunktion = PROCEDURE(REAL): REAL; 

Es wird also die Parameterliste ohne die Variablenbezeichner gebraucht. 
ProcedureType 62 


—^ PROCEDURE T 



FormalTypeList 63 


) \ * 

i * 

— 


/ 


SYNTAX: ”ProcedureType”(62) 
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SYNTAX: ”FormTypeList”(63) 


( ARRAY ) 

h-H 

C°tO 

hr- 

QualIdent -2 


_ 


SYNTAX: ”FormType”(59) 

Allgemein: Es lassen sich mit dem Typ reellePunktion nun auch Variablen erklären wie 
VAR f,g: reellePunktion; 

Nehmen wir an, wir haben eine Funktion 

PROCEDURE DritteWurzel(wert:REAL): REAL; 

BEGIN 
<r. . . > 

END DritteWurzel; 

definiert. Dann kann man diese gesamte Funktion selbst (nicht das Ergebnis der Funktion!) 
den Variablen f oder g zuweisen: 

f := DritteWurzel; 

nun ist möglich 

7 := f(x)5 

was dasselbe leistet wie 


y := DritteWurzel(x); 
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Man beachte den Unterschied zwischen den beiden Zuweisungen 

g := f; 
y := f(x); 

im ersten Fall wird eine Funktion einer Funktionsvariablen zugewiesen, im zweiten Fall ein 
REAL-Wert, nachdem eine Funktion aufgerufen wurde. Das gleiche gilt für 

g := DritteWurzel; (* Zuweisung einer Funktion *) 

y := DritteWurzel(x); (* Zuweisung des Funktions-Wertes *) 

nun wird klar, warum man beim Aufruf parameterloser Funktionen die Klammern für die 
leere Parameterliste mit angeben muß: 

fl : = f2; weist eine gesamte Funktion zu. 
y : = f 2 (); weist einen Funktionswert nach der Berechnung zu. 

Dabei macht es keinen Unterschied, ob f 2 eine Funktion oder eine PROCEDURE-Variable ist. 

Bleibt noch zu erwähnen, daß es für parameterlose Prozeduren einen eigenen Standard-Da¬ 
tentyp PROC gibt, den man sich so definiert vorstellen kann: 

TYPE PROC = PROCEDURE; 

Das folgende Programm greift die Nullstellenberechnung für verschiedene Funktionen auf. 
Weitere Beispiele findet man in Kapitel 2 und 5. 

MODULE ProzeduraleParameterDemo; 

FROM InOut IMPORT ReadReal, WriteReal, WriteString, WriteLn, Read; 

PROM MathLibO IMPORT cos, ln; 

TYPE Punktion = PROCEDURE(REAL) : REAL; 

PROCEDURE f(x : REAL) : REAL; 

BEGIN 

RETURN x - cos(x) 

END f; 

PROCEDURE g(x:REAL) : REAL; 

BEGIN 

RETURN 3.0*x*x - 8.0*x +4.0 
END g; 

PROCEDURE Nullstelle(fkt : Punktion; eps,a,b : REAL) : REAL; 

VAR mitte, sign : REAL; 
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BEGIN 

IE fkt(a) >0.0 THEN sign := -1.0 ELSE sign := 1.0 END; 

REPEAT 

mitte := (a+b) / 2.0; 

IE sign*fkt(mitte) <0.0 THEN a := mitte ELSE b := mitte 
UNTIL ABS(a-b) < eps; 

RETURN mitte 
END Nullstelle; 

VAR xl,x2,toleranz : REAL; 
taste : CHAR; 

BEGIN 

xl := 0.0; x2 := 1.0; toleranz := 1.0E-10; 

WriteString(”Die Nullstelle von ’ f(x) = x - cos(x) ’ lautet: ”); 
WriteReal(Nullstelle(f,toleranz,xl,x2),12,10); WriteLn; 
WriteString(”Die Nullstelle von ’g(x) = 3*x*x - 8*x + 4’ lautet: ”); 
WriteReal(Nullsteile(g,toleranz,xl,x2),12,10); WriteLn; 
WriteString(”Die Nullstelle von ’h(x) - ln(x) * lautet: ”); 

WriteReal(Nullstelle(ln,toleranz,0.5,10. 0), 12,10); WriteLn; 

Read(taste) 

END ProzeduraleParameterDemo. 


1.6.8 Typgleichheit, Ausdrucks- und Zuweisungs-Kompatibilität 

Sicherlich haben Sie sich beim Programmieren über so manche Compiler-Fehlermeldung 
geärgert, die mit der Kompatibilität zu tun hatte. Man muß in Modula folgendes zur Kenntnis 
nehmen: 

Typgleichheit 

Zwei Variablen xl und x2 mit den Typen Tl und T2: 

VAR xl: Tl; x2: T2; 

werden als vom selben Datentyp bezeichnet, wenn 

• Tl und T2 derselbe Name ist, zum Beispiel CARDINAL, MeinTyp; dies ist insbesondere der 
Fall, wenn xl und x2 in einer einzigen Variablendeklaration stehen: 

VAR xl,x2:Tl; 

• Tl und T2 werden in einer Typdeklaration als synonym erklärt, also mit TYPE T1 = T2; 
zum Beispiel: 
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TYPE 

str20 = ARRAY [1..19] OP CHAR; 
Zeichenkette = str20; 

VAR 

xl: str20; 

x2: Zeichenkette; 


• xl und x2 sind Variablen desselben Aufzählungstyps. 

Die folgenden Variablen xl und x2 sind jedoch von verschiedenem Typ: 

TYPE 

TI = ARRAY [0..99] OP CARDINAL; 

T2 = ARRAY [0..99] OP CARDINAL; 

VAR 

xl: TI; 
x2: T2; 


Die Zuweisung xl: =x2 ist nun nicht möglich! Eine solche Konstruktion benutzt man nur, 
um eventuell später einen Typ umzudefinieren; das Programm läuft dann trotzdem. 

TYPE 

TI = ARRAY [0. .99] OP REAL; 

T2 = ARRAY [0..99] OP CARDINAL; 


Ausdruckskompatibilität 

Zwei Operanden xl und x2 vom Typ Tl und T2 können nur in einem Ausdruck verknüpft 
werden (zum Beispiel xl+x2) wenn gilt: 

• Tl und T2 sind typgleich. 

• Tl ist ein Unterbereichstyp mit Basistyp T2 (oder umgekehrt). 

• Tl ist INTEGER oder CARDINAL und x2 eine Konstante oder vom Typ [min. . max]mit 
0 £ min, max £ MAX(INTEGER). 

• Tl ist ein beliebiger POINTER-Typ und x2 die Konstante NIL. 
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Zuweisungskompatibilität 

Es seien wieder xl und x2 vom Typ Tl und T2. Dann ist die Zuweisung xl: =x2 erlaubt, 
falls gilt: 

• xl und x2 sind ausdruckskompatibel. 

• Tl ist INTEGER oder ein Unterbereich davon und T2 ist CARDINAL oder ein Unterbe¬ 
reich davon (oder umgekehrt). Man hat bei der Zuweisung aber darauf zu achten, daß der 
Wert von x2 im Wertebereich von Tl liegt. 

• Tl = ARRAY <Bereich> OP CHAR mit 22 -Elementen 

und x2 ist eine String-Konstante mit höchstens 22 -Zeichen. Bei dieser Zuweisung werden 
die verbleibenden Zeichen mit OC aufgefüllt. Zum Beispiel: 

TYPE String20 = ARRAY [0..19] OP CHAR; 

VAR s: String20; 

<. . . > 

s := »Hallo»; 


1.7 Das Modulkonzept 

Im folgenden wird eine Idee beschrieben, die der Sprache den Namen gab: MODUlar LAn- 
guage (= »Modulare Sprache«). Es geht dabei um »lokale« Module die innerhalb von anderen 
Modulen definiert sind, sowie »externe Module«, die getrennt übersetzt werden können. 

Das Konzept ist ein mächtiges Werkzeug zum Schreiben großer Programme. Bevor wir auf die 
Einzelheiten eingehen, zunächst die grundlegenden Ideen: 

1.7.1 Das Geheimnisprinzip 

»Ach wie gut, daß niemand weiß, daß ich Rumpelstilzchen heiß!« Das ist vielleicht ein unschö¬ 
ner Charakterzug, beim Programmieren aber guter Stil. Für Variablen in Prozeduren gilt: 
»Soviel lokal wie möglich, so wenig global wie nötig!« Das folgende - hoffentlich abschrek- 
kende - Beispielprogramm unterstreicht diese These: 



Das Geheimnisprinzip 


161 


VAR i: CARDINAL; 

PROCEDURE doppelten:CARDINAL): CARDINAL; 
BEGIN 
INC(i); 

RETURN 2*n; 

END doppelt; 


Diese Prozedur wird einwandfrei kompiliert. Neben dem, was ihr Name besagt, nämlich den 
eingegebenen Wert zu verdoppeln, bastelt sie noch an der globalen Variablen i herum. Na 
und? 

Betrachten wir nun die Ausdrücke 

doppelt( 5 )+i und i+doppelt(5) 

Wenn vorher gilt i = 3 , so wird eventuell (je nach Compiler) der 

erste Ausdruck: 2*5+ (3 + 1) = 14 und der 

zweite Ausdruck: 3+2*5 = 13 


So etwas ist schwer zu durchschauen, man erwartet bei einer Summe normalerweise Ver- 
tauschbarkeit der Summanden! Schlimm ist auch doppelt ( i ). Das Ergebnis ist nicht 2*i , 
sondern 2*i+l\ 

Man spricht hierbei von »Seiteneffekten«. Die Prozedur doppelt greift auf die globale Varia¬ 
ble i zu. Besser ist es, wenn eine Prozedur nur über eine klar definierte »Schnittstelle«, und 
das sollte nur die Parameterliste sein, kommuniziert. Weitere Variablen sollten lokal sein. Sie 
sind nach außen nicht sichtbar, werden also vor dem übrigen Programm geheim gehalten. 

Modula treibt dieses Konzept noch weiter, in dem ganze Module, also Zusammenfassungen 
von Konstanten, Typen, Variablen, Prozeduren und Anweisungsteil »lokal« sein können. 
Dem »aufrufenden« übergeordneten Modul wird nur das mitgeteilt, was dieser wissen muß. 
Man spricht hierbei vom »Export« von Bezeichnern. Der Rest bleibt verborgen. 

Das hat für den Programmierer den Vorteil, daß er sich auf das Wesentliche konzentrieren kann. 
Die Details interessieren nicht, »was ich nicht weiß, macht mich nicht heiß«. Die Krönung dieser 
Idee ist der sogenannte »opake Export«, bei der sogar der Datentyp verheimlicht wird. 

Wir besprechen nun die Einzelheiten. Zunächst stellen wir das Konzept der lokalen Module 
vor (1.7.2). Danach zeigen wir, wie man selbst externe Module schreibt, die getrennt übersetzt 
werden können (1.7.3). Anschließend gehen wir auf Standardmodule ein, das sind solche Mo¬ 
dule, die bei jedem Modula-System mitgeliefert werden. Einige kennen Sie schon: inOut und 
Storage. 
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1.7.2 Lokale Module 

Gegeben ist folgendes Schema: 

MODULE Haupt; 

<. . . > 

MODULE Unter; 

<. . . > 

END Unter; 

BEGIN (* von »Haupt* *) 

<. . . > 

END Haupt. 

Unter ist hier ein lokaler Modul, also ein eigenständiger Modul innerhalb eines anderen Mo¬ 
duls. Er wird in dessen Deklarationsteil aufgeführt und hat die Form: 

MODULE <Untermodul-Name> 

<Importlisten> 

<Exportliste> 

<Deklarationsteil> 

BEGIN 

<Anwe i sungs t e i 1> 

END <Untermodul-Name>\ 

Für lokale Module gelten die gleiche Sichtbarkeitsregeln wie für Prozeduren, bis auf folgende 
Abweichungen: 

1. Ein Bezeichner eines inneren Moduls kann auch dem umschließenden Modul sichtbar ge¬ 
macht werden, indem er in der EXPORT-Liste des inneren Moduls aufgeführt wird. 

2. Bei Prozeduren sind immer auch die Bezeichner der Umgebung sichtbar, und zwar alle, die 
zu ihr »global« sind. Für Module gilt dies nicht! Module sind abgeschlossene Einheiten. 
Die außerhalb liegenden Bezeichner sind in ihnen nicht sichtbar. Soll ein Bezeichner auch 
innerhalb dieses Moduls sichtbar sein, so muß er importiert werden; das heißt, er muß in 
der IMPORT-Liste auftauchen. 

Ein lokaler Modul ist also ein in sich abgeschlossenes Programmstück, daß mit seiner Umge¬ 
bung nur über Import- und Exportlisten kommuniziert. Für den Import gelten folgende Be¬ 
sonderheiten: 

• Es dürfen auch nur die zu diesem Modul globalen Bezeichner importiert werden. Unter 
anderem kann ein lokaler Modul keine Prozeduren aus inOut importieren, wenn diese 
nicht dem umschließenden Modul bekannt sind. 
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• Wenn ein Verbund importiert wird, sind dem Modul auch dessen sämtliche Komponenten be¬ 
kannt. 


• Wenn ein Aufzählungstyp importiert wird, kennt der Modul auch alle Konstanten dieses 
Types. Man kann aber Konstanten eines Aufzählungstyp einzeln importieren. Dann sind 
allerdings weder dieser Typ noch die anderen Konstanten dieses Typs bekannt. 

Für die Import- und Exportlisten gelten folgende Diagramme: 


-►( FROM ► 

Ident i — 

V 

_ ) 


r 

-0)- 

> 

•( IMPORT 

Ident i 

1 



SYNTAX: ”Import”(65) 


r -o 

—EXPORT y 


SYNTAX: ”Export”(66) 

Wenn eine EXPORT-Liste das Schlüsselwort QUALIFIED enthält, muß der Bezeichner im 
umgebenden Modul qualifiziert benutzt werden. Das heißt, der Modulname wird mit einem 
Punkt vorangestellt ( <Modulname>.<Bezeichner> ). Zum Beispiel: 

MODULE Haupt; 

IMPORT InOut; 

MODULE Unterl; 

EXPORT QUALIEIED a; 

CONST a = 5; 

BEGIN 

END Unterl; 

MODULE Unter2; 

EXPORT Qualified a; 

CONST a = 2; 

BEGIN 

END Unter2; 

BEGIN (* Haupt *) 

InOut.WriteCard(Unterl.a + Unter2.a, 6); 

END Haupt. 


QUALIFIED 


Ident 
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Die Ausführung der Anweisungsteile von lokalen Modulen geschieht in der Reihenfolge, in 
der sie vom Compiler gelesen werden! Das folgende extreme Beispiel zeigt den Import und Ex¬ 
port von Daten und Prozeduren in extremer Weise. Vielleicht nehmen Sie sich die Zeit, nach¬ 
zuvollziehen, daß es lediglich »MODULA2« auf Bildschirm schreibt. Sämtliche anderen lo¬ 
kale Module sind wesentlich einfacher. 


MODULE LokaleModuleTest; 


PROM InOut IMPORT Write, Read, WriteCard; 
VAR n : CARDINAL; 


(*-*) 

MODULE Nix ; (* Lokaler Modul Nix *) 


EXPORT BringeU, U; 


VAR U : CHAR; 

PROCEDURE BringeU : CHAR; 

BEGIN 

RETURN U (* U wird im Anweisungsteil von 0 initialisiert *) 

END BringeU; 

(* in Nix sind nur die lokalen Objekte *U* und ’BringeU’ sichtbar*) 

END Nix; 

(*-*) 

MODULE M; (* Lokaler Modul M *) 

IMPORT Write, n; 

EXPORT mal; 

CONST x = 2; 

PROCEDURE mal(VAR c : CARDINAL); 

BEGIN 


c := x*n 
END mal; 

BEGIN Write(’M’) (* M erstes Ausgabezeichen *) 

END M; 

(* in M sind ’n’ und ’Write’ sowie die Objekte ’x’ und * mal* sichtbar *) 
(*-*) 


MODULE 0; 

IMPORT Write, n, U; 
BEGIN 

n : = 1; U : = ”U”; 
Write(”0”) 

END 0; 

(* 

(*__ - 

VAR d,taste : CHAR; 


(* Lokaler Modul 0 *) 

(* n und U werden initialisiert *) 
(* 0 wird ausgegeben *) 

in ’0’ sind ’n’, ’U’, und Write sichtbar *) 
---*) 
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BEGIN 


d := ’ D’ ; Write(d); 

Write(Bringeü()); 

Write(”L”); Write(”A”); 



(* ’D’ 

wird ausgegeben *) 

mal(n); WriteCard(n,1); 

Read(taste) 



(* ’2’ 

wird ausgegeben *) 

(* Hier sind * Write*, 

’Read’ , 

* WriteCard*, 

*n* , ’ d* ,* taste*, 


’BringeU’ , 

’U’ und 

* mal’ sichtbar *) 


END LokaleModuleTest. 


1.7.3 Benutzerdefinierte externe Module 


Jetzt geht es erst richtig los! Lokale Module ermöglichen zwar abgeschlossene Programmier¬ 
einheiten, sie müssen aber zusammen mit den übergeordneten Modulen übersetzt werden. 

Wesentlich stärker ist das Konzept der externen oder äußeren Module, die für sich getrennt 
entwickelt, getestet und kompiliert werden können. Dadurch läßt sich einerseits die Arbeit an 
einem großen Programmpaket segmentieren und auf mehrere Programmierer verteilen. Zu¬ 
dem können diese Module auch von mehreren Programmen benutzt werden. Sie kennen sol¬ 
che Module bereits vom Lieferumfang Ihres Systems her. Jetzt sollen Sie lernen, selber solche 
Module zu schreiben. 

Ein solcher externer Modul besteht aus 2 Teilen: 

• dem Definitionsmodul und 

• dem Implementationsmodul 

Im Definitionsmodul werden sämtliche Konstanten, Typen, Variablen und Prozeduren aufge- 
führt, die auch anderen Modulen zugänglich gemacht werden sollen. Eine EXPORT-Liste erüb¬ 
rigt sich deshalb. Bei Prozeduren ist nur der Prozedurkopf aufzuführen, nicht aber der Rumpf. 

Im Implementationsmodul werden die Prozeduren vollständig aufgeführt. Hier erfolgt also 
die eigentliche Ausformulierung. Zusätzlich kann ein Implementationsmodul weitere Defini¬ 
tionen und Hilfsprozeduren enthalten, die für die Implementation nötig sind, die aber von der 
Außenwelt nicht zu benutzen sind. 

Konstanten, Typen und Variablen, die im Definitionsmodul deklariert sind, werden im Im¬ 
plementationsmodul nicht noch einmal aufgeführt. 

Aus diesem Grunde muß immer zuerst der Definitionsmodul übersetzt werden, dann der zu¬ 
gehörige Implementationsmodul. Hierdurch sind letzterem die Deklarationen bekannt. Nach 
erfolgreicher Übersetzung können dann die im Definitionsmodul aufgeführten Bezeichner in 
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anderen Modulen genutzt werden. Hierzu sind sie in deren Importliste aufzuführen. Braucht 
ein externer Modul Bezeichner aus anderen Modulen, so sind diese natürlich von ihm zu im¬ 
portieren. Dieser Import kann sowohl im Implementationsmodul erfolgen (wenn die Be¬ 
zeichner nur für die Implementation gebraucht werden) als auch im Definitionsmodul (wenn 
Bezeichner aus anderen Modulen bereits im Definitionsmodul benötigt werden). 


DEFINITION ^ —» ^MODULE ) —* | Ident , KD 


r 

Import 65 

4 \ 


Definition 68 

4 \ 


z 

i 





END 


^—*> Ident [ H> 


SYNTAX: ”DeTinitionModule”(67) 


—Implementation")—» ProgramModuie, 


S YNTAX: "Implemen ta tionModule ”(68) 

Im folgenden bringen wir einige sinnvolle Beispiele, die Leistungen bereitstellen, die Sie in 
Ihren Programmen nutzen können. Im ersten Beispiel geht es um Berechnungen rund um 
das Kalenderdatum. 


Rund um das Datum 

DatumBib liefert 2 Datentypen und 14 Prozeduren. Wahrscheinlich sind Sie nun auf eine 
breite Erörterung über die Leistung des Moduls gefaßt. Wir dürfen Sie aber beruhigen, es 
kommt nichts dergleichen. Das ist auch gut so, denn die Leistungsbeschreibung soll voll aus 
dem Definitionsmodul hervorgehen. 

DEFINITION MODULE DatumBib; 

TYPE StrlO = ARRAY [0..9] OF CHAR; 

DatumTyp = RECORD 

tag : [1..31]; 
monat : [1..12]; 
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jahr : CARDINAL 
END; 

PROCEDURE heute(VAR datum : DatumTyp); 

(* Holt das Atari-Datum *) 

PROCEDURE SchaltJar(jahr : CARDINAL) : BOOLEAN; 

(* Ist das Jahr ein Schaltjahr ? *) 

PROCEDURE MonatLaenge(datum : DatumTyp) : CARDINAL; 

(* Liefert die Anzahl der Tage des Monats ’datum.monat* *) 
PROCEDURE TaglmJahr(datum : DatumTyp) : CARDINAL; 

(* Der wievielte Tag ist ’datum’ im Jahr ? *) 

PROCEDURE SchaltJahreSeitO(Jahr : CARDINAL) : CARDINAL; 

(* Anzahl der Schaltjahre seit dem 01.01.00 *) 

PROCEDURE TageSeit0(datum : DatumTyp) : LONGCARD; 

(* Berechnet die Anzahl der Tage seit dem 01.01.00 *) 

PROCEDURE TagAbstand(datl, dat2 : DatumTyp) : LONGINT; 

(* Berechnet die Differenz zweier Daten in Tagen *) 

PROCEDURE TaglnWoche(datum : DatumTyp) : CARDINAL; 

(* 1 = Montag, 2 - Dienstag, .. ,7 = Sonntag *) 

PROCEDURE NaechstTag(VAR datum : DatumTyp); 

(* Liefert das Datum des nächsten Tages *) 

PROCEDURE VorTag(VAR datum : DatumTyp); 

(* Liefert das Datum des vergangenen Tages *) 

PROCEDURE JahrHat53Wochen(Jahr : CARDINAL) : BOOLEAN; 

(* Hat das Jahr die 53. Kalenderwoche ? *) 

PROCEDURE Kalenderwoche(datum : DatumTyp) : CARDINAL; 

(* In der wievielten Kalenderwoche liegt ’datum’? *) 

PROCEDURE DatumZuString(datum : DatumTyp; VAR s : StrlO); 

(* Wandelt ein Datum in einen String der Form tt.mm.jjjj um. *) 
PROCEDURE WochenTag(datum : DatumTyp; VAR WTag : StrlO); 

(* Ermittelt den Tagesnamen eines Datums, z.B WTag = ”Montag” *) 
END DatumBib. 


Soweit die Schnittstellenbeschreibung des Moduls. Es fehlt noch die Implementation. Mögli¬ 
cherweise sind sie von ihrer Länge unangenehm überrascht. Wer sich aber den Programmtext 
kurz anschaut, wird erkennen, das jede Prozedur für sich genommen sehr einfach ist. Die Ge¬ 
samtlänge kommt nur durch die Vielzahl der Prozeduren zustande, steht also im Verhältnis 
zur Leistung des Moduls. Bis auf die Prozedur heute ist alles selbsterläuternd. Für deren 
Ausformulierung muß man das Datum von der Atari-Uhr lesen. Hierzu liefert der Modul 
GEMD0S die Prozedur GetDate. Man braucht das Datum nur noch zu dekodieren. Beachten 
Sie, das GEMD0S lediglich für den Implementationsmodul importiert wird, nicht aber im De¬ 
finitionsmodul. Schließlich geht es den Benutzer nichts an, wie wir unsere Aufgaben erledigen. 
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IMPLEMENTATION MODULE DatumBib; 

EROM GEMDOS IMPORT GetDate; 

PROCEDURE heute(VAR datum : DatumTyp); 

VAR 

DatumCode : CARDINAL; 

BEGIN 

GetDate(DatumCode); 

(* Datum kodiert als ((jahr-1900)*16 + monat)*32 + tag *) 

WITH datum DO 

tag := DatumCode MOD 32; 

DatumCode := DatumCode DIV 32; 
monat := DatumCode MOD 16; 

DatumCode := DatumCode DIV 16; 
jahr := DatumCode + 1980 
END 

END heute; 

PROCEDURE Schaltjahr(jahr : CARDINAL) : BOOLEAN; 

BEGIN 

RETURN (jahr MOD 4 = 0) & (NOT(( jahr MOD 100 = 0) & (jahr MOD 400 # 0))) 
END Schaltjahr; 

PROCEDURE MonatLaenge(datum : DatumTyp) : CARDINAL; 

BEGIN 

CASE datum.monat OE 
4,6,9,11 : RETURN 30 | 

2 : IF Schaltjahr (datum, jahr) THEN RETURN 29 ELSE RETURN 28 END 

ELSE RETURN 31 END 
END MonatLaenge; 

PROCEDURE TagImJahr(datum : DatumTyp) : CARDINAL; 

VAR 

tage, monat,EndMonat : CARDINAL; 

BEGIN 

EndMonat := datum, monat - 1; 
datum.monat := 1; 
tage := 0; 

EOR monat := 1 TO EndMonat DO 
datum.monat := monat; 

INC(tage,MonatLaenge(datum)) 

END; 

RETURN tage + datum, tag 
END TagImJahr; 
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PROCEDURE SchaltJahreSeitO(Jahr : CARDINAL) : CARDINAL; 

BEGIN 

DEC(Jahr); 

RETURN (Jahr DIV 4) - (Jahr DIV 100) + (Jahr DIV 400) 

END SchaltJahreSeitO; 

PROCEDURE TageSeitO(datum : DatumTyp) : LONGCARD; 

BEGIN 

RETURN 365L*L0NG(datum,jahr) 

+ LONG(SchaltJahreSeitO(datum.jahr) + TaglmJahr(datum)) 
END TageSeitO; 

PROCEDURE TagAbstand(datl,dat2 : DatumTyp) : LONGINT; 

BEGIN 

RETURN LONGINT(TageSeitO(datl)) - LONGINT(TageSeitO(dat2)) 

END TagAbstand; 

PROCEDURE TaglnWoche(datum : DatumTyp) : CARDINAL; 

VAR 

hilf : CARDINAL; 

BEGIN 

hilf : = SHORT((TageSeitO(datum) - 1L ) MOD 7L ); 

IE hilf = 0 THEN RETURN 7 ELSE RETURN hilf END 
END TaglnWoche; 

PROCEDURE NaechstTag(VAR datum : DatumTyp); 

BEGIN 

WITH datum DO 

IE tag = MonatLaenge(datum) THEN 
tag := 1; 

monat := monat MOD 12 + 1; 

IF monat = 1 THEN INC(jahr) END 
ELSE INC(tag) END 
END 

END NaechstTag; 

PROCEDURE VorTag(VAR datum : DatumTyp); 

BEGIN 

WITH datum DO 
IF tag = 1 THEN 

IE monat = 1 THEN DEC(jahr); monat:=12 ELSE DEC(monat) END; 
tag := MonatLaenge(datum) 

ELSE DEC(tag) END 
END 
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END VorTag; 

PROCEDURE JahrHat53Wochen(Jahr : CARDINAL) : BOOLEAN; 

VAR Neujahr : DatumTyp; 

BEGIN 

WITH Neujahr DO tag := 1; monat := 1; jahr:=Jahr + I END; 

RETURN TaglnWoche(Neujahr) IN {5,6) 

END JahrHat53Wochen; 

PROCEDURE Kalenderwoche(datum : DatumTyp) : CARDINAL; 

VAR Neujahr : DatumTyp; 

hilf,KaWoche : CARDINAL; 

BEGIN 

WITH Neujahr DO tag:=1; monat:=1; jahr:=datum. jahr END; 
hilf := TaglnWoche(Neujahr); 

KaWoche := (TaglmJahr(datum) + hilf - 2 ) DIV 7; 

IP hilf < 5 THEN INC(KaWoche) END; 

IP (KaWoche = 53) & NOT(JahrHat53Wochen(datum, jahr)) THEN KaWoche:=1 

ELSIP KaWoche=0 THEN VorTag(Neujahr); KaWoche: = Kalenderwoche(Neujahr) END; 
RETURN KaWoche; 

END Kalenderwoche; 

PROCEDURE DatumZuString(datum : DatumTyp; VAR s 
VAR 

pos : CARDINAL; 

BEGIN 

s[2]:= ”; s[5]:”; 

WITH datum DO 

s[0] := CHR(tag DIV 10 + 0RD(”0”)) ; s[l] 
s[3] := CHR(monat DIV 10 + 0RD(”0”)) ; s[4] 

POR pos := 9 TO 6 BY -1 DO 

s[pos] := CHR(jahr MOD 10 + 0RD(”0”)) ; 
jahr := jahr DIV 10 
END; 

END; 

END DatumZuString; 

PROCEDURE WochenTag(datum : DatumTyp; VAR WTag : StrlO); 

BEGIN 

CASE TaglnWoche(datum) OP 

1 : WTag := "Montag" | 

2 : WTag := "Dienstag” | 

3 : WTag := "Mittwoch” | 

4 : WTag := "Donnerstag”! 


: StrlO); 


(* s = ”_._._" *) 

:= CHR(tag MOD 10 + 0RD(”0")); 
:= CHR(monat MOD 10 + 0RD(”0")); 
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5 : WTag := "Freitag” j 

6 : WTag := "Samstag” j 

7 : WTag := "Sonntag" j 

END 

END WochenTag; 

END DatumBib. 


Zum Austesten des Moduls bringen wir ein kleines Demonstrationsprogramm, was einen 
großen Teil der Prozeduren aufruft. An der Importliste erkennen Sie, das sich die Benutzung 
eines selbstverfaßten Moduls in keiner Weise von der des Modula-Systems unterscheidet. 

Noch ein Hinweis zur Handhabung: Wenn Sie nicht das Megamax-System benutzen, 
benennen Sie zunächst den Filenamen DATUMBIB.D in DATUMBIB.DEF und DA¬ 
TUMBIB.I in DATUMBIB.MOD um (das müssen sie bei allen Definitions- bzw. Implemen¬ 
tationsmodulen tun). Übersetzen Sie anschließend den Definitionsmodul, dann den Imple¬ 
mentationsmodul. Sorgen Sie dafür, daß diese Objekt-Dateien in einem Ordner landen, den 
der Compiler bei der anschließenden Übersetzung des Hauptmoduls DATUM.MOD findet. 
Hierzu sind die Suchpfade des Systems geeignet voreinzustellen (siehe Handbuch). Nennen 
Sie diesen Ordner einfach OBJEKTE. Dort sollten sich im Laufe der weiteren Lektüre dieses 
Buches sämtliche Übersetzungen der externen Module sammeln. Dies ist wichtig, da im fol¬ 
genden andere Module auf diesen Modulen aufbauen. 

Megamax-Benutzer finden alle Übersetzungen der externen Module im Ordner OBJEKTE. 
Machen Sie Ihrem Compiler diesen Ordner bekannt (Suchpfad in SHELL.INF angeben) und 
beginnen Sie gleich mit der Übersetzung von DATUM.M. 

MODULE DatumDemo; 

FROM InOut IMPORT WriteLn, WriteString, WriteCard, Write, Writelnt, 

Read, ReadCard; 

FROM DatumBib IMPORT DatumTyp, StrIO, heute, Schaltjahr, MonatLaenge, 

TaglmJahr, TagAbstand, TaglnWoche, Kalenderwoche, 

NaechstTag, VorTag, DatumZuString, WochenTag; 

PROCEDURE SehreibDatum(datum : DatumTyp); 

VAR DatumStr, TagName : StrIO; 

BEGIN 

WochenTag(datum, TagName); 

WriteString(TagName); WriteString(”, der ”); 
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DaturaZuString(datum,DatumStr); 

WriteString(DatumStr); WriteLn; 

END SehreibDatum; 

VAR datum, datum2 : DatumTyp; 
ch : CHAR; 

t, m, j : CARDINAL; 

BEGIN 

heute(datum); 

WriteString(”Heute ist ”); SehreibDatum(datum); 

WriteString(”Es ist der ”);WriteCard(TagImJahr(datum), 1); 

WriteString(”. Tag in diesem Jahr.”); WriteLn; 

WriteString(”Wir befinden uns in der ”); WriteCard(KalenderWoche(datum),1); 
WriteString(”. Kalenderwoche.”); WriteLn; 

WriteString(”Dieser Monat hat ”); 

WriteCard(MonatLaenge(datum),1); WriteString(” Tage.”); WriteLn; 
WriteString(”Dieses Jahr ist ”); 

IF NOT SchaltJahr(datum.jahr) THEN Write(”k”) END; 

WriteString(”ein Schaltjahr.”); WriteLn; 

NaechstTag(datum); WriteString(”Morgen ist ”); SehreibDatum(datum); 

VorTag(datum); 

WriteLn; WriteString(”Geben Sie ein zweites Datura ein :”); WriteLn; 

REPEAT 

REPEAT WriteString(”Tag: ”); ReadCard(t) UNTIL (0 < t) & (t < 32); 

REPEAT WriteString(”Monat: ”); ReadCard(m) UNTIL (0 < m) & (m < 13); 
WriteString(”Jahr: ”); ReadCard(j); 

WITH datumS DO tag := t; monat := m; jahr : = j END; 

UNTIL t <= MonatLaenge(datura2); (* das Datura ist gültig *) 

WriteString(”Abstand zwischen heute und dem eingegebenen Datum in Tagen: ”); 
Writelnt(TagAbstand(datum2,datum),1); 

Read(ch) 

END DatumDemo. 


Externer Modul für komplexe Arithmetik 

Das folgende Beispiel ist etwas mathematischer. 

Es handelt sich um die Implementierung von Grundrechenarten bei komplexen Zahlen. Wir 
benötigen diesen Modul im 4. Kapitel bei der Erzeugung von Grafiken der »Mandelbrot- 
Menge« (auch als »Apfelmännchen« bekannt) und der »Julia- Mengen«. 



Benutzerdefinierte externe Module 


173 


Wenn Ihnen die zugrundeliegenden 
mathematischen Sachverhalte nicht 
bekannt sind, hier eine kurze Ein¬ 
führung. 

Gegeben sei im Koordinatenkreuz 
ein Pfeil vom Nullpunkt zum Punkt 
(3, 2). Wir schreiben dafür 

zl: =3+2i 

und sprechen von einer komplexen 
Zahl (allgemein z=a+bi). Hierbei 
heißt a Realteil und b Imaginär¬ 
teil. Unter dem »Betrag« |z| ver¬ 
stehen wir die Länge des Pfeils, also 
in unserem Beispiel X /Tl, allgemein 
(Satz des Pythagoras): 

| z | = Ja 2 +b 2 oder 

|z| 2 = a 2 +b 2 

Weiterhin sei noch eine zweite 
komplexe Zahl gegeben, sagen wir 

z2:=2+4i. 

Dann definiert man 

z = zl+z2 = (3+2i)+(2+4i) 

= 5 + 6i 

Mit dieser Definition ist z die Dia¬ 
gonale des von zl und z2 aufge¬ 
spannten Parallelogramms. 

Entsprechend definiert man 



Bild 1.32: Die komplexe Zahl z = 3 + 2i 


Imaginäre Achse 



zl-z2 = (3+2i)-(2+4i) 
= l-2i 


Bild 1.33: Summe zweier komplexer Zahlen 
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zl schließe den Winkel a (hier 
33.7°) mit der reellen Achse ein und 
z2 den Winkel ß (hier 63.4°). Man 
definiert das Produkt zl*z2 als 
diejenige komplexe Zahl - darge¬ 
stellt als Pfeil - die den Winkel 
a +ß mit der reellen Achse ein¬ 
schließt und als Länge das Produkt 
|zl|*|z2| annimmt. 

Für 

(0+li)(O+li) = i*i = i 2 

ergibt sich dann -1. Allgemein gilt 

zl*z2=(a+bi)(c+di) 

=ac+adi+bci+bdi 2 
=ac+adi+bci+bd(-1) 

=(ac-bd) +(ad+bc)i 
Realteil Imaginärteil 

In unserem Beispiel ist also 

zl*z2=(3+2i)*(2+4i) 

=(6-8)+(12+4)i 
=2+16i 

Für z 2 gilt: 

z 2 = (a+bi) 2 = (a 2 -b 2 )+2abi 

Die Division ist nun einfach: 

zl _ a+bi _ (a+bi)(c-di) _ (ac+bd)+(bc-ad)i 
z2 c+di (c+di)(c-di) c 2 +d 2 

Übertragen auf das Zahlenbeispiel ergibt sich: 

zl _ 3 + 2i = (6+8)+(4-12)i = 14-8i 
z2 2+4i 



4 + 16 


20 


0.7-0.4i 
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Wir implementieren im folgenden Bibliotheksmodul ComplexLib die Grundrechenarten, 
|z| 2 , z 2 , und drei Umwandlungsfunktionen: re, im und cmplx: 

DEFINITION MODULE ComplexLib; 

TYPE complex = RECORD re,im : REAL END; 

PROCEDURE re(z : complex) : REAL; (* gibt den Realteil von z *) 

PROCEDURE im(z : complex) : REAL; (* gibt den Imaginärteil von z *) 

PROCEDURE cmplx(r,i : REAL) : complex; (* gibt z :=(r,i) *) 

PROCEDURE abs2(z : complex) : REAL; (* gibt Betrag(z)*Betrag(z) *) 


PROCEDURE 

addc(zl, z2 : 

complex) : 

complex; 

(* 

gibt 

zl 

+ 

z2 

*) 

PROCEDURE 

subc(zl,z2 : 

complex) : 

complex; 

(* 

gibt 

zl 

- 

z2 

*) 

PROCEDURE 

mulc(zl,z2 : 

complex) : 

complex; 

(* 

gibt 

zl 

* 

z2 

*) 

PROCEDURE 

divc(zl,z2 : 

complex) : 

complex; 

(* 

gibt 

zl 

/ 

z2 

*) 

PROCEDURE 

sqrc(z: complex) : complex; 

(* 

gibt 

z 

* 

z 

*) 


END ComplexLib. 

Die Implementation ist einfach: 

IMPLEMENTATION MODULE ComplexLib; 

PROCEDURE re(z : complex) : REAL; 

BEGIN 

RETURN z.re 
END re; 

PROCEDURE im(z : complex) : REAL; 

BEGIN 

RETURN z.im 
END im; 

PROCEDURE cmplx(r,i : REAL) : complex; 
VAR z : complex; 

BEGIN 

z. re:=r; z. im:=i; 

RETURN z 
END cmplx; 

PROCEDURE abs2(z : complex) : REAL; 
BEGIN 

RETURN z.re*z.re + z. im*z. im 


END abs2; 
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PROCEDURE addc(zl,z2 : complex) : complex; 
VAR z : complex; 

BEGIN 

z.re:=zl.re+ z2.re; 
z.im:=zl.im+ z2.im; 

RETURN z 
END addc; 

PROCEDURE subc(zl,z2 : complex) : complex; 
VAR z : complex; 

BEGIN 

z.re:=zl.re-z2.re; 
z.im:=zl.im-z2.im; 

RETURN z 
END subc; 

PROCEDURE raulc(zl,z2 : complex) : complex; 
VAR z : complex; 

BEGIN 

z.re:=zl.re*z2.re - zl.im*z2.im; 
z.im:=zl.re*z2.im + zl.im*z2.re; 

RETURN z 
END mulc; 

PROCEDURE divc(zl,z2 : complex) : complex; 
VAR z : complex; 

n :. REAL; 

BEGIN 

n: =abs2(z2); 

z. re:=(zl.re*z2.re + zl. ira*z2.im)/n ; 
z.im:=(zl.im*z2.re - zl.re*z2.im)/n; 
RETURN z 
END divc; 

PROCEDURE sqrc(z: complex) : complex; 

VAR s : complex; 

BEGIN 

s.re:=z.re*z.re - z.im*z.im; 
s.im:=2. 0*z. re*z. im; 

RETURN s 
END sqrc; 

END ComplexLib. 
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ExternerModul zur Tastaturbehandlung 

Das dritte Beispiel führt Sie schon in Atari-interne Bereiche. 

Die Standardprozedur Read, kann nur die Tasten lesen, die einen ASCII-Code haben, nicht 
also die Cursortasten und Funktionstasten. Benutzt man die Prozedur BConln aus dem Mo¬ 
dul BIOS, so wird beim Drücken einer Taste ein LONGCARD-Wert zurückgegeben. 

im unteren Byte steht der ASCII-Code der Taste (falls vorhanden, sonst 0). Im dritten Byte der 
sogenannte ScanCode (das ist die Nummer der Taste auf der Tastatur, zum Beispiel 1 für 
<Esc>, 2 für die Taste <1> usw.). 

Mit der Prozedur GetKBShift kann man zusätzlich fragen, ob eine der Metatasten <Shift>, 
<Control>, < Alternate> oder <Capslock> gedrückt wurde. Die Prozedur des folgenden Mo¬ 
duls erlaubt es, »normale« Tasten und Sondertasten zu lesen. Zu einigen oft gebrauchten Ta¬ 
sten werden Konstanten zur Verfügung gestellt, die in Anlehnung an die Definition des Mo¬ 
duls SWiSS von SPC-Modula entstanden sind. Sie erweitern sozusagen den ASCII-Code über 
den Bereich 0..255 hinaus. Aus diesem Grunde geben wir keinen CHAR-Wert, sondern eine 
CARDINAL-Zahl zurück. 

DEFINITION MODULE Tastatur; 


CONST (* die wichtigsten Sondertasten *) 




PHoch = 256; PTief = 257; 

PLinks = 

258; 

PRechts 

= 259 

(* Pfeiltasten *) 





SHoch = 356; STief = 357; 

SLinks = 

358; 

SRechts 

= 359 

(* Shift-Pfeiltasten *) 
Help = 260; Undo = 261; 

Insert = 

262; 

Clear = 

263; 


Fl = 283; F2 = 284; F3 = 285; F4 = 286; F5 = 287; 

F6 = 288; F7 '= 289; F8 = 290; F9 = 291; F10 = 292; 

(* Funktionstasten *) 

PROCEDURE AlleTasten(VAR megataste, scan, ascii : CARDINAL); 

(* 

* Gibt den ASCII-Wert und den Scan-Code einer Taste zurück. 

* megataste gibt den Zustand der Shift, Alternate, Control und 

* Capslock Taste an. 

* 0 = keine megataste gedrückt, 1 = rechte Shifttaste, 2 = linke, 

* 4 - Controltaste, 8 = Alternatetaste, 16 = Capslocktaste, 

* Bei Kombinationen hiervon gilt die Summe. 

*) 
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PROCEDURE lies(VAR c : CARDINAL); 

(* 

* Liest eine Taste. Gibt den ASCII-Wert zurück oder eine der 

* oben implementierten Sondertastenwerte. 

* Für andere Tasten wird Null zurückgegeben. 

*) 

END Tastatur. 

IMPLEMENTATION MODULE Tastatur; 

FROM SYSTEM IMPORT BYTE; 


FROM BIOS IMPORT KBShifts, Device, 

BConln, GetKBShift; 

PROCEDURE AlleTasten(VAR megataste, 

scan, ascii : CARDINAL); 

VAR 1c 

: LONGCARD; 


m 

: KBShifts; 


b 

: BYTE; 


BEGIN 



1c : = 

BConln(CON); 

(* 4 Byte-Wert *) 

ascii 

:= SHORT(lc MOD 256L); 

(* unteres Byte *) 

lc : = 

lc DIV lOOOOHL; 

(* 2. Byte konstant = 0 *) 

scan 

:= SHORT(lc MOD 256L); 

(* 3. Byte *) 

m : «' 

GetKBShift(); 

(* 4. Byte *) 


megataste := CARDINAL(LONG(BYTE(m))); 

END AlleTasten; 

PROCEDURE lies(VAR c : CARDINAL); 

VAR mt,sc,as : CARDINAL; 

shift : BOOLEAN; 

BEGIN 

AlleTasten(mt,sc,as); 

shift := (mt =1) OR (mt = 2) OR (mt * 16); 

(* rechte oder linke Shift-Taste oder Caps-Lock gedrückt? *) 


CASE 

59 

sc 

: OF 

c : = 

Fl 1 

60 


c : = 

F2 | 

61 


c : = 

F3 j 

62 


c : ~ 

F4 ) 

63 


c : = 

F5 1 

64 


c : = 

F6 | 

65 


c : = 

F7 | 

66 


c : = 

F8 i 
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67 : 

c : 

= F9 | 


68 : 

c : 

= F10| 


71 : 

c : 

=Clear| 


72 : 

IP 

shift THEN 

c : = 

75 : 

IP 

shift THEN 

c : = 

77 : 

IP 

shift THEN 

c : = 

80 : 

IP 

shift THEN 

c : = 

82 : 

c : 

= Insert | 


97 : 

c : 

= Undo | 


98 : 

c : 

= Help | 


ELSE c 

: - 

as END; 



END lies; 

END Tastatur. 


SHoch 

ELSE 

c 

:= PHoch 

END 

SLinks 

ELSE 

c 

:= PLinks 

END 

SRechts 

ELSE 

c 

:= PRechts 

END 

STief 

ELSE 

c 

:r PTief 

END 


Externe Module können wiederum andere externe Module aufrufen. Das ist das schöne in 
Modula! Man kann sich auf diese Weise ganze Modulbibliotheken aufbauen. Unser Modul 
Tastatur baut auf dem Modul BIOS auf. Die Dienste von Tastatur nutzt nun ein weiterer 
Modul Eingabe, den wir im folgenden vorstellen. 

Eingabe gibt die Möglichkeit einer komfortablen Eingabe auf dem TOS-Bildschirm. Hier¬ 
mit lassen sich Eingabemasken erstellen, mit denen man Zeichenketten und Zahlen eingeben 
kann. Das ist zwar etwas altmodisch für den Atari, da man hier schöne »Dialogboxen« mit 
GEM kreieren kann, doch diese Techniken werden erst im vierten Kapitel behandelt. 

Wir werden diesen Modul für eine Dateiverwaltung im Abschnitt 2.3.2. nutzen. 

Das Einlesen von Zeichenketten und Zahlen ist mit unserem Modul etwas komfortabler als 
mit InOut.ReadString bzw. ReadCard. Megamax-Modula bietet hier aber bereits stan¬ 
dardmäßig gute Editiermöglichkeiten. 

DEFINITION MODULE Eingabe; 

PROM DatumBib IMPORT DatumTyp; 

PROCEDURE Glocke; 

(* 

* Bewirkt Ertönen der Warnglocke. 

*) 

PROCEDURE LiesZeichen(gueltig : ARRAY OP CHAR) : CHAR; 

(* 

* Liest ein Zeichen ( OC < Z <= 377C) von der Tastatur, das in 

* ’gueltig’ enthalten ist. Andere Zeichen werden nicht akzeptiert. 

*) 




180 


Das Modulkonzept 


PROCEDURE LiesWort(x, y : CARDINAL; 

laenge : CARDINAL; 

VAR wort : ARRAY OF CHAR; 

VAR EndTaste : CARDINAL); 

(* 

* Liest die Zeichenkette ’wort’ von der Tastatur ein. 

* ’wort’ hat maximal ’laenge’ Zeichen. 

* Die übergebene Zeichenkette wird zunächst bei (x,y) auf den 

* Bildschirm geschrieben. Sie wird ggfs, auf ’laenge’ gekürzt. 

* Das restliche Eingabefeld wird mit Unterstrichen markiert. 

* Die Eingabe ist mit den Tasten Linkspfeil, Rechtspfeil, 

* Backspace und Delete edierbar. 

* ClrHome löscht die bestehende Zeichenkette. 

* Die Insert-Taste schaltet zwischen Einfüge- und Überschreibemodus 

* um. Vorbelegt ist der Überschreibemodus. 

* Die Eingabe wird mit den Tasten Return, Escape und den Pfeiltasten 

* oben, unten, Shift Pfeil links und Shift Pfeil rechts beendet. 

* Diese Taste wird der Variable ’EndTaste’ zur Weiterverarbeitung 

* durch das aufrufende Programm zur Verfügung gestellt. 

* Damit lassen sich einfach Eingabemasken erstellen. 

*) 

PROCEDURE LiesCard(x, y : CARDINAL; 

min, max : CARDINAL; 

VAR wert : CARDINAL; 

VAR EndTaste : CARDINAL); 

(* 

* Liest die Kardinalzahl ’wert’ ein. 

* Hierbei wird sichergestellt, daß gilt: min <= wert <= max. 

* Die Prozedur ermittelt selbst die benötigt Stellenzahl für ’wert’. 

* Die übrigen Parameter sind wie bei ’Lieswort’. 

* Die Eingabe ist wie bei ’LiesWort’ edierbar. 

*) 

PROCEDURE LiesDatum(x,y : CARDINAL; 

VAR datum : DatumTyp; 

VAR EndTaste : CARDINAL); 

(* 

* Liest ein Datum ein (mit Überprüfung auf Gültigkeit). 

* Schreibt das übergebene Datum an Stelle (x,y) auf den Bildschirm. 

* Das Datum ist mit den Pfeiltasten edierbar. Die Punkte im Datum 

* braucht der Anwender nicht zu tippen. 

* Die übrigen Parameter sind wie bei ’Lieswort’. *) 

END Eingabe. 
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Zunächst werden beim Einlesen soviele Unterstriche auf den Bildschirm geschrieben, wie das 
einzugebende Wort maximal hat (Maske). Das übergebene Wort wird angegeben. Folgende 
Sondertasten werden interpretiert: 

• Pfeiltasten links/rechts zur Cursorsteuerung 

• <Delete> zum Löschen des Zeichens, auf dem der Cursor steht 

• <Backspace> zum Löschen des Zeichens links vom Cursor 

• <Clr Home> zum Löschen des gesamten Wortes, der Cursor steht an der ersten Position 

• <Insert> schaltet um zwischen Einfüge-Modus und dem Überschreibe-Modus. Der Mo¬ 
dus bleibt bestehen, bis erneut die <Insert>-Taste getippt wird. Der Überschreibe- Modus 
ist vorbelegt. 

• Diverse Tasten zur Beendigung der Eingabe: Pfeiltasten nach unten und oben, <Shift>- 
Pfeiltaste rechts, < Return> und <Esc>. Sie werden der Variablen EndCh übergeben zur 
Weiterverarbeitung im aufrufenden Programm. 

Mit einer Pfeiltaste kann auf das nächste Eingabefeld unterhalb/oberhalb/rechts/links in einer 
Eingabemaske gesprungen werden. <Return> ist die Standard-Abbruchstaste und sollte ei¬ 
nen Sprung auf das nächste Eingabefeld bewirken. <Esc> kann zum Abbruch des gesamten 
Dialogs genutzt werden. Doch zunächst der Implementationsmodul. Die Prozeduren sind 
hier etwas länger, aber trotzdem leicht verständlich, da die unterschiedlichen Eingabesteue¬ 
rungen übersichtlich in CASE-Strukturen abgehandelt werden. Hier gleich ein Tip: Immer 
wenn sich eine längere Fallunterscheidung nach Konstanten selektieren läßt, bietet die 
CASE-Anweisung die eleganteste Lösung. 

IMPLEMENTATION MODULE Eingabe; 

IMPORT Strings; 

IMPORT StrConv; 

PROM InOut IMPORT Write, GotoXY, WriteString, WriteCard; 

PROM Tastatur IMPORT PLinks, PRechts, PHoch, PTief, 

SLinks, SRechts, SHoch, STief , 

Insert, Clear, lies; 

PROM DatumBib IMPORT DatumTyp, StrlO, MonatLaenge, DatumZuString; 

CONST ESC = 27; RET = 13; BS = 8; DEL = 127; 

PROCEDURE Glocke; 

BEGIN Write(7C) END Glocke; 

PROCEDURE CursorAn; 
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BEGIN Write (33C); Write(”e”) END CursorAn; 

PROCEDURE CursorAus; 

BEGIN Write(33C); Write(”f”) END CursorAus; 

PROCEDURE LiesZeichen(gueltig : ARRAY OP CHAR) 

VAR c : CARDINAL; 

BEGIN 
LOOP 

lies(c); 

IP (c > 255) OR (c = 0) THEN Glocke 

ELSIP Strings.Pos(CHR(c),gueltig, 0 ) = 

ELSE Write(CHR(c)); RETURN(CHR(c)) END 

END 

END LiesZeichen; 

PROCEDURE LiesWort(x, y : CARDINAL; 

laenge : CARDINAL; 

VAR wort : ARRAY OP CHAR; 

VAR EndTaste : CARDINAL); 

VAR 

c, pos, i : CARDINAL; 

ok, fertig, einfuegen : BOOLEAN; 

BEGIN 

Strings.Copy(wort,0,laenge,wort,ok); 

GotoXY(x,y); WriteString(wort); 

POR i : ~ Strings.Length(wort)+1 TO laenge DO Write(”_”) END; (^Markierung*) 
pos := 0; 

fertig := PALSE; einfuegen :=PALSE; 

CursorAn; 

REPEAT 

GotoXY(x+pos, y); 

lies(c); (* beliebige Taste ohne Echo lesen *) 

CASE c OP 

32.. 126, 

128.. 255 : IP einfuegen THEN 

IP Strings.Length(wort) = laenge THEN Glocke ELSE 
Strings.Insert(CHR(c),pos, wort, ok); 

POR i:=pos TO Strings.Length(wort)-1 DO Write(wort[i]) END; 
INC(pos); 

END 

ELSE 

IP pos = laenge THEN Glocke ELSE 
Strings.Delete(wort,pos, 1, ok); 


: CHAR; 

(* Taste ohne Echo lesen *) 
- 1 THEN Glocke 
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Strings.Insert(CHR(c), pos, wort, ok); 

Write(CHR(c)); INC(pos); 

END 
END t 

PRechts : IP pos = Strings.Length(wort) THEN Glocke ELSE INC(pos) END | 

PLinks : IP pos = 0 THEN Glocke ELSE DEC(pos) END 1 

BS : IP pos = 0 THEN Glocke ELSE 

DEC(pos); 

Strings.Delete(wort,pos, 1, ok); 

Write(CHR(BS)); 

POR i:=pos+l TO Strings.Length(wort) DO Write(wort[i-l]) END; 
Write(”_”) 

END | 

DEL : IP pos = Strings.Length(wort) THEN Glocke ELSE 

Strings.Delete(wort, pos, 1, ok); 

POR i:= pos+1 TO Strings.Length(wort) DO Write(wort[i-l]) END; 
Write() 

END | 

Insert : einfuegen := NOT einfuegen | 

Clear : wort[0] := OC; pos := 0; GotoXY(x,y); 

POR i := 1 TO laenge DO Write(”_”) END | 

ESC, RET, PHoch, PTief, SLinks, SRechts, SHoch, STief 
: EndTaste := c; fertig := TRUE | 

ELSE Glocke 
END; 

UNTIL fertig; 

CursorAus; 

pos := Strings.Length(wort); 

GotoXY(x+ pos,y); 

POR i := pos+1 TO laenge DO Write(” ”) END; (* restliche Striche löschen *) 
END LiesWort; 

PROCEDURE LiesCard(x,y : CARDINAL; 

min, max : CARDINAL; 

VAR wert : CARDINAL; 

VAR EndTaste : CARDINAL); 

VAR 

s, Zahlwort : Strings.String; 

stellen,pos, hilf : CARDINAL; 
gueltig : BOOLEAN; 

BEGIN 

s := StrConv. CardToStr(LONG(max), 1); (* Stellen von ’max’ ermitteln *) 

stellen := Strings.Length(s); (* = maximal benötigte Stellenzahl *) 

IP (wert < min) OR (wert > max) THEN wert : = min END; 
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LOOP 

Zahlwort := StrConv.CardToStr(LONG(wert), 1); 

LiesWort(x,y,stellen,Zahlwort,EndTaste); 
pos : = 0; 

hilf : = StrConv.StrToCard(Zahlwort,pos, gueltig); 

gueltig := gueltig & (pos = Strings.Length(Zahlwort)) (* Zeichen ok ? *) 
& (min < = hilf) & (hilf <= max); (* Bereich ok ? *) 
IE NOT gueltig THEN Glocke ELSE EXIT END 
END; 

wert := hilf; 

GotoXY(x,y); POR pos := 1 TO stellen DO Write(” ”) END; (* Eing.feld lö. *) 
GotoXY(x,y); WriteCard(wert,stellen) (* Zahl rechtsbündig ausgeben *) 

END LiesCard; 


PROCEDURE LiesDatum(x,y 


: CARDINAL; 


VAR datum : DatumTyp; 
VAR EndTaste : CARDINAL); 


VAR 


fertig, gueltig : BOOLEAN; 

c, pos, t, m, j : CARDINAL; 

s : StrlO; 

HilfDatum : DatumTyp; 


altes Datum hinschreiben:_._._*) 

Position im Datum: pos = 0123456789 *) 


BEGIN 
REPEAT 

DatumZuString(datum,s); 

GotoXY(x,y); WriteString(s); 
fertig:=PALSE; 
pos := 0; 

CursorAn; 

REPEAT 

IP (pos = 2) OR (pos = 5) THEN INC(pos) END; (* Punkte überspringen *) 
GotoXY(x+ pos,y); 


Write(CHR(c)); INC(pos) 


cke ELSE INC(pos) END) 
ESC, RET, PHoch, PTief, SLinks, SRechts, SHoch, STief 
: EndTaste := c; fertig := TRUE | 

ELSE Glocke END 


lies(c); 


CASE 

pq 

o 

o 


48 

. . 57 : 

IP pos < 10 THEN 

s[pos]:=CHR(c) 

ELSE Glocke END 

PLinks : 

IP pos = 0 THEN i 

IP (pos=2) OR (p 

PRechts : 

IP pos =10 THEN 
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UNTIL 

t: =0; 

fertig; 

POR pos 

: = 0 

TO 

1 DO 

t : 

= 10*t + 0RD(s[pos] )- 

0RD(”0”) 

END; 

m: =0; 

POR pos 

: = 3 

TO 

4 DO 

m : 

= 10*m + 0RD(s[pos] )- 

0RD(”0”) 

END; 

j: =0; 

POR pos 

: = 6 

TO 

9 DO 

3 *• 

= 10*j + 0RD(s[pos] )- 

0RD(”0”) 

END; 

gueltig := (0 

< t 

) & 

(t < 

32) 

& (0 < m ) & (m <13); 




IP gueltig THEN 

WITH HilfDatum DO tag:=t; monat:=m; jahr:= j END; 
gueltig:=( t < = MonatLaenge(HilfDatum)) 

END; 

UNTIL gueltig; 
datum := HilfDatum; 

CursorAus; 

END LiesDatum; 

END Eingabe. 

Die Eingabe von Zahlen wurde nur für CARDINAL-Zahlen implementiert. Analog kann man 
eine Eingabe für die übrigen numerischen Typen schreiben. Mit dem folgenden kleinen Test¬ 
programm können Sie die Einzelheiten der Eingabeprozeduren ausprobieren: 

MODULE EingabeDemo; 

PROM InOut IMPORT WriteLn, Write, WriteString, WriteCard, WritePg, GotoXY; 
PROM DatumBib IMPORT DatumTyp, StrlO, DatumZuString; 

IMPORT Eingabe; 

CONST max =10; 

VAR Wort : ARRAY [0..max] OP CHAR; 

DatumStr : StrlO; 
ende, z : CARDINAL; 
datum : DatumTyp; 

BEGIN 

Wort:= ”Hallo”; z:= 300; datum.tag: = 1; datum.monat: = 1; datum.jahr:= 1990; 
REPEAT 
WritePg; 

WriteLn; WriteString(”Test des Moduls ’Eingabe’ .”); 

WriteLn; WriteString("Tippen Sie Worte ein, testen Sie Sondertasten!”); 
Eingabe.LiesWort(2,5,max+1,Wort,ende); 

WriteString(” Eingabe: ”); WriteString(Wort); 

WriteString(” EndTaste : ”); WriteCard(ende, 1); 
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WriteLn; WriteLn; WriteString(”Tippen Sie Zahlen zwischen 0 und 1000 ein!”); 
WriteLn; WriteString(”Testen Sie auch Buchstaben und zu große Zahlen!”); 
Eingabe.LiesCard(2,10,0,1000,z, ende); 

WriteString(” Eingabe: ”); WriteCard(z, 1); 

WriteString(” EndTaste = ”); WriteCard(ende, 1); 

WriteLn; WriteLn; WriteString(”Tippen Sie ein Datura ein!”); 

WriteLn; WriteString(”Testen Sie auch Buchstaben und ungültige Daten!”); 
Eingabe.LiesDatum(2,15,datum, ende); 

DatumZuString(datum,DaturaStr); 

GotoXY(17,15); WriteString(”Eingabe: ”); WriteString(DatumStr); 

WriteString(” EndTaste = ”); WriteCard(ende,1); 

WriteLn; WriteLn; WriteString(”Wollen Sie Weitermachen (j/n)? ”); 

UNTIL CAP(Eingabe.LiesZeichen(”jJnN”)) = ”N” 

END EingabeDemo. 


Eine Anwendung des Moduls Eingabe zeigt die Dateiverwaltung im Kapitel (2.3.2). 

In den weiteren Kapiteln werden viele solche allgemeinnützliche externe Module vorgestellt, 
auf diese Weise entsteht eine kleine Bibliothek. 


1.7.4 Externe Standardmodule 

Die Sprache Modula selbst ist mit Absicht möglichst knapp gehalten worden, schließlich kön¬ 
nen weitere Funktionen einfach aus externen Modulen importiert werden. Daher werden 
standardmäßig eine Reihe von externen Modulen mitgeliefert. Hierzu gehört im allgemeinen: 

InOut 

Ein- und Ausgabe über Bildschirm und Tastatur; Umleitemöglichkeit für Drucker und 
Dateien 

ReallnOut 

Erweiterung von InOut für REAL-Zahlen (nur bei einigen Systemen) 

Terminal 

Minimale, zeichenweise Ein- und Ausgabe nur für Bildschirm und Tastatur; eignet sich be¬ 
sonders für den TOS-Bildschirm 

Strings 

Für Stringoperationen 

MathLib oder MathLibO 

Mathematische Funktionen auf dem Typ real 
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Files oder FileSystem 

Ein- und Ausgabe für Dateien (Files) 

Storage 

Speicherverwaltung für dynamische Variablen 
SYSTEM 

ein Pseudomodul, der direkt zur Sprache gehört. Genaues siehe unten. 

Bei den Atari-Systemen gibt es zusätzlich einige Module, die Schnittstellen zum Betriebs¬ 
system liefern wie BIOS, XBIOS und GEMDOS und die GEM-Module zu AES, VDI und 
Line-A-Graphik. 

Darüber hinaus werden je nach Lieferumfang des Modula-Systems mehr oder weniger nützli¬ 
che Module mitgeliefert, die aber im allgemeinen keinem Standard entsprechen. Hierzu gehö¬ 
ren noch eine Reihe von Modulen zur Konvertierung von Datentypen und zu speziellen 
Zwecken wie zum Beispiel zum Lesen der Atari-Uhr. Wie gesagt, diese Module sind nicht ge¬ 
normt und leider deshalb von Modula-System zu Modula-System verschieden. Wir werden 
deshalb nicht großartig darauf eingehen. Zu inOut sind bereits viele Beispiele gegeben 
worden. Beispiele zu Stringbehandlung hatten wir im letzten Abschnitt. Die Dateibehandlung 
wird in Kapitel 2.3 besprochen. Zu Storage wurde schon das Wichtigste in Abschnitt 1.6.6 
gesagt; siehe auch Kapitel 2. 

Bleibt noch der Modul SYSTEM. 

Der Modul SYSTEM 

Der Modul SYSTEM gehört zu jedem Modula-System. Hier findet man systemabhängige Pro¬ 
zeduren und die Typen BYTE, WORD, LONGWORD und ADDRESS. Da diese Datentypen und Pro¬ 
zeduren rechnerabhängig sind, werden sie nicht als Bestandteil der Sprache angesehen, son¬ 
dern in den »Pseudo«-Modul SYSTEM ausgelagert. SYSTEM ist eigentlich Bestandteil des 
Compilers; es gibt auch keinen Definitionsmodul dazu. Der Grund dafür liegt darin, daß SY¬ 
STEM einige Prozeduren enthält, die in Modula nicht auszudrücken sind (siehe unten VAL). 

SYSTEM stellt die »Joker-Typen« BYTE, WORD, LONGWORD und ADDRESS bereit. Sie sind kom¬ 
patibel zu allen anderen Typen, wenn sie in der Parameterliste von Prozeduren auftreten. Le¬ 
diglich der Speicherbedarf muß mit dem der übergebenden Argumente übereinstimmen, also 
1 Byte bei BYTE, 2 Byte bei WORD und 4 Byte bei LONGWORD. 
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Beispiel: 

FROM SYSTEM IMPORT BYTE, WORD, LONGWORD; 

VAR 

ch : CHAR; 
c : CARDINAL; 
i : INTEGER; 
bs : BITSET; 

1c : LONGCARD; 
li : LONGINT; 

PROCEDURE pB (b:BYTE); 

BEGIN 
<. , . > 

END pB; 

PROCEDURE pW (w:WORD); 

BEGIN 
<. . . > 

END pW; 

PROCEDURE pL (1:LONGWORD); 

BEGIN 
<. . . > 

END pL; 


Dann sind folgende Aufrufe korrekt: 

pB(ch); 

pW(c); pW(i); pW(bs); 

pL(lc); pL(li); 

Wir haben diese Methode bereits im Programm BitSetTest aus Abschnitt 1.3.7 benutzt. 
Schauen Sie sich dieses Beispiel noch einmal an. 

An formale Parameter vom Type ARRAY OE BYTE, ARRAY OF WORD, ARRAY OF LONGWORD 
können Daten beliebiger Länge übergeben werden; einschließlich Verbünde und Felder. Wir 
werden hiervon in Kapitel 2 Gebrauch machen. Mit diesen Datentypen kann man sehr flexible 
typunabhängige Prozeduren schreiben! 
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Bei manchen Modula-Implementationen haben BYTE, WORD und LONGWORD diese Joker- 
Funktion nicht nur in Parameterlisten, sondern sie sind zuweisungskompatibel mit jedem Da¬ 
tentyp der gleichen Länge. Folgendes ist dann erlaubt: 


MODULE WordTest; 

PROM SYSTEM IMPORT WORD; 
VAR 

n: CARDINAL; 
b: BITSET; 
w: WORD; 

BEGIN 

b := {1,3,5}; 
w : = b; 
n : = w 

END WordTest. 


Weiterhin stellt SYSTEM den Datentyp ADDRESS bereit, der kompatibel zu jedem Pointer ist. 
Also 

<. .. > 

PROM SYSTEM IMPORT ADDRESS; 

VAR 

p: POINTER TO TI; 
q: POINTER TO TI; 
a: ADDRESS 

BEGIN 
a : = p; 
q : = a 
<. . . > 

ist möglich! 

Folgende Prozeduren Findet man in SYSTEM: 

ADR (x) address (Adresse) 

Funktion; übergibt die Adresse der Variablen x. x ist von beliebigem Typ, der 
Ergebnis-Typ ist ADDRESS. 
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TSIZE(T) type-size (»Typ-Größe«) 

Funktion mit einem Typ T als Argument. Ergibt den Speicherbedarf des Typs T. Ergeb¬ 
nis ist LONGCARD. 

VAL (T, c) vcilue (»Wert«) 

Wandelt den CARDINAL-Ausdruck c in den skalaren Typ T um. Damit ist die Funktion 
das Gegenteil der Standardfunktion ORD. Somit ist bei VAR x: T; 

ORD(VAL(T,x))= x und 
VAL(T,ORD(x))= x, 

falls keiner der Werte zu groß für den anderen Typ ist. Damit läßt sich die Standardfunk¬ 
tion CHR(c) darstellen als VAL(CHAR, c). Bei manchen Compilern ist VAL allerdings als 
universelle Konvertierungs-Funktion implementiert: T kann dabei jeder Typ und c von 
jedem Typ sein. 

Diese drei Prozeduren enthält jeder SYSTEM-Modul. Darüber hinaus gibt es noch Prozedu¬ 
ren zur Behandlung von Coroutinen. Diese sind bei manchen Systemen ausgelagert; man fin¬ 
det sie dann in einem Modul Coroutines. 

Das folgende Beispiel demonstriert den Umgang mit SYSTEM: 

MODULE SYSTEMTest; 

PROM SYSTEM IMPORT TSIZE, VAL, ADR; 

PROM InOut IMPORT WriteString, WriteCard, WriteLHex, WriteLn, Write, Read; 

VAR taste : CHAR; 
x, y : REAL; 

BEGIN 

WriteString(”Größe von LONGCARD: ”); WriteCard(TSIZE(LONGCARD), 8); 
WriteString(” Bytes”); WriteLn; 

WriteString(»Typumwandlung *A* : ”); WriteCard(VAL(CARDINAL,”A”),8); 
WriteString(” als Kardinalzahl = ASCII- Wert”); WriteLn; 

WriteString(»Adresse von x : ”); WriteCard(ADR(x),8); 

WriteString(” dezimal = ”); WriteLHex(ADR(x),8); 

WriteString(” hexadezimal”); WriteLn; 

WriteString(»Adresse von y : ”); WriteCard(ADR(y),8); 

WriteString(” dezimal = ”); WriteLHex(ADR(y), 8); 

WriteString(” hexadezimal”); WriteLn; 

Read(taste); 

END SYSTEMTest. 
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1,7.5 Software-Engineering und Modulhierarchien 

Wie wir gesehen haben, können externe Module außer Prozeduren auch Variablen, Daten¬ 
typen und Konstanten bereitstellen. In unseren Beispielen kommt dies alles in Mischform vor. 
Man unterscheidet folgende Modulklassen als Reinformen: 

1. Funktionsmodule 

2. Datenmodule 

3. Datenkapseln 

4. Abstrakte Datentypen (ADT) 

Zu 1. 

Hier werden nur Prozeduren zu Verfügung gestellt (Beispiel Abschnitt 2.1; Modul 
Felder). 

Zu 2. 

Hier werden nur Konstanten und (oder Datentypen) exportiert. Ein Beispiel ist der Modul 
GemGlobals in Megamax-Modula oder ASCII von Hänisch- oder SPC-Modula. 

Zu 3. 

Hier wird eine Datenstruktur implementiert, der Zugriff ist aber nur über die exportierten 
Prozeduren möglich. Die Realisierung bleibt dem Benutzer verborgen. Ein Beispiel findet 
man in Abschnitt 2.2; Stapel. 

Zu 4. 

Hier wird nur der Name (!), nicht aber der Typ eines Datentyps exportiert, sowie Prozedu¬ 
ren, die auf dem Datentyp arbeiten. Die konkrete Realisierung des Datentyps bleibt dem 
Benutzer verborgen. Er braucht sich darum nicht zu kümmern. Die Typdeklaration muß 
natürlich im Implementationsmodul erfolgen. Beispiele sind Schlange und Baum im 
2. Kapitel. 

Mit eigenen externen Modulen und mitgelieferten Standardmodulen kann man übersichtlich 
komplexe Softwarepakete erstellen. Dies sei am Beispiel des Eingabe-Moduls aus dem letzten 
Abschnitt erläutert: 

Definitions- und Implementationsmodul stützen sich auf die mitgelieferten Module Strings, 
StrConv und InOut, sowie auf unsere Module DatumBib und Tastatur. DatumBib stützt 
sich auf den Betriebssystem-Modul GEMDOS. Tastatur benötigt wiederum SYSTEM und 
BIOS. Der Eingabe-Modul wird nun seinerseits im zweiten Kapitel von einem Modul Datei - 
Verwaltung benutzt, der sich wiederum auf etliche andere Module stützt, unter anderem 
auch auf Tastatur. Man erhält also folgende Hierarchie: 
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Bild 1.35: Modulhierarchien 

Dieses Beispiel zeigt, daß Module sich in beliebiger Tiefe aufrufen können. Das Prinzip der 
hierarchischen Unterteilung von Programmen gab der Sprache Modula den Namen. Es wer¬ 
den damit zwei Ziele erreicht: 

• Abstraktionshierarchien, wie sie bei der »Top-down«-Entwicklung von Algorithmen ent¬ 
stehen, können unmittelbar in eine entsprechende Modulstruktur überführt werden. 

• Es bleibt alles schön übersichtlich, da man bei der Entwicklung höherer Module nur die 
Definitionsmodul kennen muß, die Details der Implementation sind uninteressant. 

Die sich hieraus ergebenden Vorteile seien noch einmal zusammengefaßt: 

• Es können Modulbibliotheken erstellt werden. Bei einem neuen Programmierprojekt 
braucht man nicht jedesmal »das Rad neu zu erfinden«. 
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• Modula-2 eignet sich hervorragend für die Erarbeitung großer Software-Pakete auch im 
Team. 

• Durch Kapselung von Compiler- oder rechnerspezifischen Details erreicht man eine hohe 
Portabilität der Programme. 


1.8 Coroutinen und parallele Prozesse 

Stellen Sie sich vor, Sie hätten einen Super-Atari mit zwei 68000-Prozessoren. Der eine Prozes¬ 
sor könnte eine komplizierte Berechnung durchführen, während der andere gerade eine Datei 
ausdruckt. 

Man spricht hier von nebenläufigen (= gleichzeitigen) Prozessen. So etwas geht mit Modula, 
auch mit nur einem Prozessor! Jedenfalls sieht es für den Benutzer eines Programms so aus, als 
ob zwei Prozesse gleichzeitig abliefen. Auch für den Programmierer ist die Sichtweise so. 

Der Rechner realisiert das dann allerdings intern folgendermaßen: Er arbeitet nacheinander 
an den jeweiligen Prozessen und wird zwischen den Prozessen dauernd hin und her geschaltet 
(Zeitmultiplex-Verfahren). Wenn die Steuerung der Ablaufkontrolle explizit durch einen 
Umschaltvorgang erfolgt, spricht man von »Coroutinen«, wenn sie nach einem »Ablauffahr¬ 
plan« erfolgt, von Prozessen. 

Eine Coroutine kann ihren Ablauf unterbrechen, ihren momentanen Zustand einfrieren und 
den Programmablauf einer anderen Coroutine überlassen. Beim Einfrieren des Zustandes 
werden alle Registerinhalte und die Adresse der Unterbrechungsstelle auf einem gesonderten 
Speicherbereich »gerettet«. Wenn die Coroutine wieder an der Reihe ist, arbeitet sie so, als 
wäre zwischendurch nichts geschehen. Also bleiben auch Werte lokaler Variablen erhalten! 

In Modula kann man aus Prozeduren Coroutinen machen. Dies funktioniert nur mit parame¬ 
terlosen und nicht-rekursiven Prozeduren. Diese Prozeduren dürfen auch nicht Unterproze¬ 
duren von anderen Prozeduren sein. 

Die Kommunikation zwischen den Coroutinen wird also nur durch globale Variablen abge¬ 
wickelt. Das tut der Sache aber keinen Abbruch. Um die Sichtbarkeitsbereiche von Variablen 
begrenzt zu halten, kann man einen lokalen Modul benutzen. 

Prozeduren für parallele Prozesse 

Die benötigten Prozeduren für dieses Konzept sind NEWPROCESS und TRANSFER; bei man¬ 
chen Systemen kommt noch IOTRANSFER, IOCALL und LISTEN hinzu. Man findet sie übli¬ 
cherweise im Pseudomodul SYSTEM oder in einem separaten Modul Cor out ine s. 

Wie macht man nun aus einer Prozedur eine Coroutine? Hierzu dient die Prozedur 
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PROCEDURE NEWPROCESS(p: PROC; 

Arbeitsspeicher: ADDRESS; 

ArbeitsspeicherGroesse: CARDINAL; (* Megamax: LONGCARD *) 
VAR neuerProzess: ADDRESS); 

Hiermit wird für die parameterlose Prozedur (Datentyp: PROC, vgl. 1.6.7) ein Prozeß erzeugt. 
Dieser Prozeß benötigt einen Arbeitsspeicher, den man mit übergeben muß. Als Ergebnis er¬ 
hält man in neuerProzess die Coroutinen-Adresse des Prozesses. 

Beispiel: 

PROCEDURE TuWas; 

BEGIN <. . . > END TuWas; 

VAR Arbeitsspeicher: ADDRESS; 

TuWasProzess : ADDRESS; 

<. . . > 

Storage.ALLOCATE(Arbeitsspeicher, 1000D); 

NEWPROCESS(TuWas, Arbeitsspeicher, 1000D, TuWasProzess); 

Hierdurch wird aus der Prozedur TuWas die Coroutine TuWasProzess. Den benötigten Spei¬ 
cherplatz holen wir uns hier mittels ALL0CATE vom Heap. Wir hätten auch einfach die 
Adresse eines 1000-Byte großen Feldes (VARfeld: ARRAY[0. . 999] 0FCHAR) übergeben 
können: 

NEWPROCESS(TuWas,ADR(feld), 1000L, TuWasProzess); 

Die Coroutine haben wir nun, aber ihr Zustand ist noch »schlafend«. Mit 
TRANSFER(VAR quelle, ziel: ADDRESS); 

weckt man sie und friert gleichzeitig die aufrufende Coroutine oder das aufrufende Programm 
ein. Die Adresse der aufrufenden Coroutine wir in quelle abgelegt, hier kann durch einen 
erneuten Aufruf von TRANSFER- jetzt mit vertauschten Parametern - mit der Arbeit fortge¬ 
fahren werden. Aufrufe von TRANSFER ermöglichen also die Weiterarbeit am letzten Unter¬ 
brechungspunkt. 

Hier laufen drei Routinen parallel: 

1. Eine reelle Zahl wird laufend um 1 erhöht, quadriert und ausgedruckt. 

2. Auf den Drucker werden fortlaufend Zeichen ausgegeben. 
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3. Die Tastatur wird dauernd abgefragt. Eventuell eingegebene Zeichen werden auf den Bild¬ 
schirm geschrieben. 

Die folgende Demonstration zeigt den Umgang mit Coroutinen. 


MODULE CoroutinenDemo; 


FROM SYSTEM IMPORT NEWPROCESS, TRANSFER, ADDRESS, ADR, BYTE; 

PROM GEMDOS IMPORT PrnOS; 

PROM InOut IMPORT GotoXY, WriteReal, Write, WriteString, BusyRead; 

PROM Piles IMPORT Pile, Open, Close, Access; 

IMPORT Text; 


VAR TransAdr 


pr 

PROCEDURE quadrat; 

VAR x : REAL; 

BEGIN 

x := 1.0; 

LOOP 

x: = x + 1.0; 

GotoXY(10,10); 

WriteReal(x,4,2); 

WriteString(” -> ”); 

WriteReal(x*x,10,2); 

TRANSFER(TransAdr.quadrat,TransAdr.druck) 

END 

END quadrat; 

PROCEDURE druck; (-»Dank Coroutinekonzept funktioniert diese *) 

VAR (»Prozedur sogar ohne Drucker! Sie gibt ohne *) 

ch : CHAR; (»Drucker sofort wieder die Kontrolle weiter ») 

BEGIN 

ch : = ” ”; 

LOOP 

IP PrnOS() THEN (»Wenn der Drucker bereit ist *) 

Text.Write(pr, ch); 

IP ch = CHR(llO) THEN ch := ” ”;Text.Writeln(pr) ELSE INC(ch) END; 


: RECORD 

HauptPrg, 

quadrat, druck, taste : ADDRESS 
END; 

: Pile; 
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END; 

TRANSFER(TransAdr.druck,TransAdr. taste) 

END; 

END druck; 

PROCEDÜRE taste; 

VAR key : CHAR; 

BEGIN 

LOOP 

BusyRead(key); (»Wenn eine Taste gedrückt wurde *) 

IF key # OC THEN 

GotoXY(10,15); Write(key); 

IF key = 33C THEN TRANSFER(TransAdr. taste, TransAdr. HauptPrg) END 
END; 

TRANSFER(TransAdr.taste, TransAdr.wurzel) 

END 

END taste; 

VAR Platz : RECORD 

quadrat, druck, taste : ARRAY [0..1999] OF BYTE 
END; 

BEGIN 

Open(pr,”PRN:”,writeSeqTxt); 

NEWPROCESS(wurzel,ADR(Platz.quadrat),SIZE(Platz. quadrat), TransAdr. quadrat); 
NEWPROCESS(druck,ADR(Platz.druck),SIZE(Platz. druck), TransAdr. druck ); 
NEWPROCESS(taste,ADR(Platz.taste),SIZE(Platz. taste), TransAdr.taste ); 

GotoXY(20,2); WriteString(”Coroutinen Demo, Abbruch mit ESC”); 

GotoXY(20,4); WriteString(”Bitte den Drucker einschalten!”); 

GotoXY(20, 5); WriteString(”Es laufen 3 Prozesse parallel:”); 

(♦Wenn eine Taste gedrückt wurde *) 

GotoXY(20,6); WriteString(”Berechnung, Tastaturabfrage mit Echo Druck.”); 

TRANSFER(TransAdr.HauptPrg,TransAdr. taste); 

Close(pr); 

END CoroutinenDemo. 
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Bei diesem Programm haben wir Endlos-Schleifen eingesetzt. Eine Coroutine endet nämlich 
nicht, sondern sie gibt ihre Kontrolle ab. Das Ende einer Coroutine bedeutet das Ende des 
Programms. Man erkennt an diesem Beispiel weiter, daß das Hauptprogramm auch zur Co¬ 
routine wird. 

Vielleicht fragen Sie sich nach diesem Beispiel, wozu überhaupt das Coroutinen-Konzept gut 
sein soll. Ohne dieses hätte man das Beispielprogramm auch schreiben können. Da nur ein 
Prozessor vorhanden ist, wird ja sowieso alles nacheinander abgearbeitet. 

Die Antwort: Sicherlich läßt sich auch ohne die Parallel-Programmierung auskommen. Sie ist 
aber in vielen Fällen praktisch, da der Progammierer die einzelnen Coroutinen unabhängig 
voneinander programmieren kann. Die Umschaltung überläßt er dem System. Ebenso gut 
könnte man ja auch ohne Verwendung von Prozeduren programmieren, aber wer will diesen 
Komfort schon missen? 

Typische Einsatzgebiete von Coroutinen sind locker gekoppelte Vorgänge, bei denen nur we¬ 
nige Daten übertragen werden müssen. Ein Beispiel wäre die Programmierung eines Welt¬ 
raumspiels, bei dem mehrere Objekte mit wenigen Wechselwirkungen umherfliegen. Für jedes 
Objekt schreibt man hier eine Coroutine. Ein seriöses Beispiel ist der Kompilierungsvorgang. 
Hier sind das Scannen, Parsen und die Codeerzeugung relativ lose gebunden. 


1.9 Hinweise zum guten Programmierstil in Modula-2 

Hierzu ist an verschiedenen Stellen bereits etwas gesagt worden. Das folgende kann als Richt¬ 
schnur dienen. Wir halten uns jedoch auch nicht immer sklavisch daran. 

Die Verwendung von Konstanten 

1. Konstanten machen ein Programm übersichtlicher und portierbarer 

2. Besser als 

VAR feld: ARRAY [0..999] 0F T; 
ist 

CONST 

max = 999; 

VAR 

feld: ARRAY[0..max] 0F T; 
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3. Die zweite Version ist wesentlich leichter abzuändern (Aspekt der Wartbarkeit von Pro¬ 
grammen). Es ist einfacher, das Feld bei Bedarf größer zu machen, so daß Konstrukte wie 

FOR i := 0 TO max DO feld[i]:=0 END; 

immer noch wie gewünscht arbeiten. 

Die Verwendung von Prozeduren 

Prozeduren sollten so bezeichnet werden, daß aus ihnen hervorgeht, was sie tun. Umgekehrt 
sollten sie auch nicht mehr machen, als ihr Bezeichner aussagt. 

Für Funktionen verwendet man vorzugsweise Substantive, die die Werte beschreiben, die sie 
liefern. Bei Booleschen Funktionen benutzt man auch Adjektive (zum Beispiel leer) oder 
Partizipien (gefunden). Alle übrigen Prozeduren tun etwas, daher verwendet man Verben 
(meist Infinitiv (Einrichten) oder Imperativ (Schreibe)). 

Eine Prozedur sollte nicht allzu lang sein, sonst verliert man den Überblick. Ein guter Rich¬ 
twert sind die 25 Zeilen des Bildschirms. Einzeiler sind erlaubt. 

Prozeduren in großen Programmen sollten möglichst nur über die klar ersichtliche Schnitt¬ 
stelle Parameterliste kommunizieren und nicht mit globalen Variablen operieren, da dies zu 
unerwünschten Seiteneffekten führen kann. Auf jeden Fall sollten die Laufvariablen stets 
lokal sein. 

Kommen in der Parameterliste einer Prozedur mehrere Variablen vor, so setzt man Eingabe¬ 
variablen nach vorne und Ausgabevariablen nach hinten. Variablen, die sowohl eine Eingabe 
liefern als auch modifiziert werden, kommen dazwischen. 

PROCEDURE Kopiere(quelle: Typ; VAR ziel: Typ); 

Insgesamt sollte die Anzahl der Variablen einer Prozedur nicht allzu hoch sein. Faustregel: 
Über fünf wird es unübersichtlich. 

Externe Module 

Größere Teilaufgaben, vor allem wenn sie öfter Vorkommen, gehören in einen externen Mo¬ 
dul. Dies erspart auch Zeit bei der Entwicklung von Programmen, da man separat kompilieren 
und testen kann. 

Jeder Modul sollte nur einen beschränkten Satz an Prozeduren enthalten, die sich einer ge¬ 
meinsamen Aufgabenstellung überordnen lassen. Keinesfalls sollte hier ein Wirrwarr von ver¬ 
schiedenen Aufgabenstellungen erledigt werden (»Können wir diese Prozedur noch brau¬ 
chen?« - »Nee, aber packen wir sie mal in den Modul...«). 
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Der Definitionsmodul sollte deutlich machen, was die Prozeduren leisten. In den meisten Fäl¬ 
len ist hier eine zusätzliche Kommentierung hilfreich. Kommentare über die Funktionsweise 
gehören allerdings nur in das Implementationsmodul. Der Definitionsmodul sollte auch mög¬ 
lichst knapp gehalten werden. 

Man sollte sich im Einzelfall überlegen, ob man einen Import in der Version ohne FR0M nicht 
einem Import mit FR0M vorzieht. Im ersten Fall sind die Bezeichner dieses Moduls bei der 
Verwendung qualifiziert zu verwenden. Dies führt zwar zu mehr »Tipparbeit«, falls der Be¬ 
zeichner öfters verwendet wird, hat aber den Vorteil, daß man im Programmtext sofort sieht, 
aus welchem Modul er stammt; der Name ist so aussagekräftiger. 

Beim Import aus Standardmodulen ist allerdings der Import mit FORM üblich. 

Die äußere Form von Programmen 

Hierzu gehören vernünftige Kommentare und Einrückungen. Kommentare dienen sicherlich 
dazu, ein Programm lesbarerzu machen, wenn man an ihnen schnell den Zweck der kommen¬ 
tierten Stelle erkennen kann, ohne sich mühevoll durch Prozeduraufrufe und mysteriöse Poin¬ 
terzuweisungen quälen zu müssen. Unsinnig sind allerdings Kommentare wie 

a : = 3; (*a wird 3 zugewiesen*) 

An dieser Stelle ein kleiner Trick mit Kommentarklammern: Man kann sie in der Testphase 
auch einsetzen, um Programmpassagen für den Compiler auszublenden. Hierbei können 
Kommentare selbst wieder von Kommentarklammern eingeschlossen werden. Das macht 
nichts, denn Modula unterstützt geschachtelte Kommentare: 

(*Dies ist ein (*geschachtelter*) Kommentar*) 

Für Einrückungen gilt nur eine Regel: Sinnvoll ist das, was übersichtlich ist. Dummerweise hat 
davon jeder seine eigene Vorstellung, deshalb läßt sich schwer ein Standard festlegen. 

Auf jeden Fall wird das Programm unübersichtlich, wenn man Zeilenumbrüche nur macht, 
weil die Zeile gerade zu Ende ist. Man kann aber durchaus einmal zwei Anweisungen in eine 
Zeile setzen: 

WriteLn; WriteString("Ergebnis”); WriteReal(x,5); 

Und 

F0R i := 0 TO max DO feld[i] = 0 END; 


ist oft besser als 
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FOR i := 0 TO max 
DO 

feld[i] : = 0 
END; 

Sicherlich sollten Schachtelungen eingerückt werden. Professionelle Programmierer nehmen 
oft einen ganzen Tabulatorschritt (TAB = 8 Leerzeichen) was etwas reichlich ist; andererseits 
ist ein einziges Leerzeichen pro Ebene zu wenig, weil man dann schon ein Lineal anlegen muß, 
um festzustellen, was zusammengehört. 

Wir hoffen, mit unserer Formatierung eine Version gebracht zu haben, an der man sich orien¬ 
tieren kann. 
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Eine Standardaufgabe der Datenverarbeitung ist das Abspeichern großer Datenmengen und 
anschließend das schnelle Wiederfinden bestimmter Daten. Die Daten lassen sich in 
Modula-2 mittels der Datenstrukturen Feld, Liste oder Baum im Speicher unterbringen; dar¬ 
über hinaus besteht die Möglichkeit, die Daten (mit Hilfe dieser Strukturen) auf Dateien zu 
schreiben. Die Verwendung von verzeigerten Strukturen wird im Kapitel 2.2 besprochen, die 
von Dateien im Kapitel 2.3; zunächst geht es um Felder. 

2.1 Die Behandlung von Feldern 

Ziel dieses Abschnitts ist es, einen Modul zur Behandlung von Feldern beliebigen Datentyps 
(Suche und Sortierung) zu geben. 

Als Beispiel für einen solchen Datentyp möge der folgende Verbund KundenTyp dienen: 
TYPE 

str20 = ARRAY [0..19] OF CHAR; 
str30 = ARRAY [0..29] OF CHAR; 

KundenTyp = RECORD 

KundenNr : CARDINAL; 

Name, Vorname : str20; 

Strasse : str30; 

PLZ : [1000..9999]; 

Ort : str20 

END; 


mit dem Feld 


VAR feld : ARRAY [0..99] OF KundenTyp; 

Sind in einem solchen Feld nun alle 100 Kunden mit ihrer Anschrift eingelesen, so kommt es 
vor, daß man (zum Beispiel innerhalb eines Fakturierungs-Programmes) zu einer Kunden¬ 
nummer die entsprechende Kundenanschrift wissen will; das Feld muß nach der Kunden¬ 
nummer durchsucht werden. Die Kundennummer bildet den »Schlüssel« für den Zugriff auf 
die benötigten Daten, die man unter dem entsprechenden Feldindex feld [ i ] findet. Abstra¬ 
hierend können wir also von einem Feld der Form 

C0NST max = 99; 

TYPE verbünd = RECORD 

schluessel : CARDINAL; 

Information : InfoTyp 
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END; 

VAR feld : ARRAY [0..max] OP verbünd; 


ausgehen. 

Sequentielles Suchen in einem Feld 

Bezeichnen wir mit gesucht einen vorgegebenen Schlüssel (hier eine bestimmte Kunden¬ 
nummer), so ist das Feld nach dem Index i zu durchsuchen, für den gilt: 

gesucht = feld[i].schluessel. 

Wir formulieren dies sogleich in einer Prozedur, wobei das gesamte Feld von Anfang an durch¬ 
laufen wird, solange bis der gesuchte Schlüssel gefunden ist. Diesen Vorgang nennt man »se¬ 
quentielles Suchen«. Die Funktionsprozedur gibt den gesuchten Index zurück, mit dem dann 
auf den gesamten Verbund (mit Name, Anschrift etc.) zugegriffen werden kann. Ist der 
Schlüssel nicht vorhanden, wird max+l zurückgegeben, damit das aufrufende Programm er¬ 
kennt, daß die Suche fehlgeschlagen ist. 

PROCEDURE SequentielleSuche(gesucht: CARDINAL): CARDINAL; 

VAR i: CARDINAL; 

BEGIN 

FOR i := 0 TO max DO 

IF feldfi].schluessel = gesucht THEN RETURN i END; 

END; 

RETURN max + 1 
END SequentielleSuche; 

Sobald also der gesuchte Schlüssel gefunden ist, wird der entsprechende Index i mittels 
RETURN als Ergebnis zurückgegeben und die Prozedur (einschließlich der FOR-Schleife) abge¬ 
brochen. Nur wenn der Schlüssel nicht vorhanden ist, wird die FOR-Schleife vollständig durch¬ 
laufen und max+l zurückgegeben. 

Schlüssel sind aber nicht immer CARDINAL-Zahlen, sondern es sind zum Beispiel bei Namen, 
Bestellnummern usw. oft Zeichenketten üblich. Dann läßt sich die Gleichheitsabfrage in der 5. 
Zeile nicht einfach mit dem Gleichheitszeichen durchführen. So importiert man - um Zei¬ 
chenketten vergleichen zu können - die Prozedur Compare und den Typ Relation aus dem 
Modul Strings. Die Abfrage lautet dann: 


IF Compare(feld[i].schluessel,gesucht) = equal THEN RETURN i END; 
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Bei dem Algorithmus »sequentielle Suche« ist mindestens eine Gleichheitsabfrage nötig, 
maximal max+l. Wenn wir davon ausgehen, daß alle Schlüssel gleichwahrscheinlich sind, 
benötigt man im Mittel max/2+1 Vergleiche. Bei sehr großen Feldern (größenordnungs¬ 
mäßig max>l00) ist dieses einfache Verfahren vor allem bei häufiger Suche zu langsam. Dann 
ist es sinnvoll, das Feld zunächst nach Schlüsseln aufsteigend zu sortieren und dann mittels 
»binärem Suchen« zu durchsuchen, was im folgenden beschrieben werden soll. 

Binäres Suchen in einem geordnetem Feld 

Als Beispiel greifen wir der Einfachheit halber wieder auf ein Feld mit CARDINAL-Schlüsseln 
zurück. Die Daten im Feld seien so abgespeichert, daß gilt: 

feld[i]. schluessel<feld[ j ]. schluessel für alle i< j . 

Im Klartext: das Feld ist nach Schlüsseln aufsteigend sortiert, so daß links die Elemente mit 
den »kleinen« Schlüsseln, rechts die mit den »großen« stehen. 

Nun können wir beim Suchen nach einem Schlüssel folgendermaßen Vorgehen: Wir testen zu¬ 
nächst, ob die Feldkomponente mit dem »mittlerem Index« feld[ mitte]. schluessel der 
gesuchte Schlüssel ist; wobei wir mitte: = (links+rechts) DIV 2 setzen. Es gibt dann drei 
Fälle: 

1. Der Schlüssel ist gefunden. 

2. Es gilt feld[mitte], schluessel<gesucht, dann kann sich der gesuchte Schlüssel 
nur im rechtem Teilfeld befinden. Wir durchsuchen nun das Feld vom Index mi tte+l an, 
das heißt, die Suche wird mit links: =mitte+l wiederholt. 

3. Es gilt feld[mitte] . schluessel>gesucht. Man hat dann im linken Teilfeld weiterzu¬ 
suchen, folglich wird rechts: =mitte-l gesetzt und mit der Suche fortgefahren. 

Insgesamt ergibt sich damit als erste Version die Prozedur: 

(* schlechte Version! *) 

PROCEDURE BinaereSuche(gesucht: CARDINAL): CARDINAL; 

VAR links,rechts,mitte: CARDINAL; 
gefunden: BOOLEAN; 

BEGIN 

links := 0; rechts := max; 
gefunden := PALSE; 

REPEAT 

mitte := (links + rechts) DIV 2; 

IF feld[mitte].schluessel = gesucht THEN gefunden := TRUE END; 

IF feld[mitte].schluessel < gesucht 
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THEN links := mitte + 1 
ELSE rechts := mitte - 1 END 
UNTIL gefunden OR (links>rechts); 

IP gefunden THEN RETURN mitte ELSE RETURN max+ 1 END 
END BinaereSuche; 


Diese Prozedur läßt sich aber noch verbessern. Die Wahrscheinlichkeit, direkt das gesuchte 
Element zu finden, beträgt 1/n (n = Anzahl der Feldelemente). Es ist somit unwahrscheinlich, 
daß die Schleife frühzeitig abbricht. Die Abbruchsbedingung der REPEAT-Schleife ist kom¬ 
pliziert und innerhalb der Schleife befinden sich gleich zwei IF-Abfragen. Trotzdem wird diese 
Prozedur in den meisten Lehrbüchern so formuliert. Wir machen es kürzer: Wir prüfen zu¬ 
nächst, ob das mittlere Feldelement feld[mitte]einen kleineren Schlüssel hat als gesucht. 
Wenn ja, suchen wir im Teilfeld feld[mitte+l] bis feld[max] weiter, ansonsten in der 
anderen Hälfte feld[0] bis feld[mitte] . So fahren wir mit der Halbierung des Feldes fort, 
bis es nur noch aus einer Komponente besteht. Entweder ist dies die gesuchte oder aber der 
Schlüssel ist nicht vorhanden und es wird max+l als Fehlanzeige zurückgegeben. 

PROCEDURE BinaereSuche(gesucht: CARDINAL): CARDINAL; (* schnellere Version *) 

VAR links, rechts, mitte: CARDINAL; 

BEGIN 

links := 0; rechts := max; 

WHILE links < rechts DO 

mitte := (links + rechts) DIV 2; 

IP feld[mitte].schluessel < gesucht THEN links := mitte+1 
ELSE rechts := mitte END 

END; 

IP feld [links].schluessel = gesucht THEN RETURN links (* gefunden *) 

ELSE RETURN max + 1 END (* nichts gefunden *) 

END BinaereSuche; 


Auf der Diskette finden sie das Programm SuchDemo, mit dem Sie im einzelnen sehen können, 
wie beide Verfahren arbeiten. 

Für String-Schlüssel importiert man aus dem Modul Strings die Prozedur Compare und den 
Typ Relation. Die 7. und die 10. Zeile müssen dann so lauten: 

IP Compare(feld[i].schluessel,gesucht) = less THEN <. ..> 

IP Compare(feld[i].schluessel,gesucht) = equal THEN <. ..> 

Der Vorteil des Verfahrens liegt auf der Hand: hat man zum Beispiel n = 1024 Feldelemente, so 
erfolgen innerhalb der Schleife nur 10 Vergleiche, da das zu durchsuchende Feld jedesmal hal- 
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biert wird. Hinzu kommt noch die Probe auf Gleichheit nach Abschluß der Schleife. Insgesamt 
sind also 11 Vergleichsoperationen notwendig, unabhängig davon, ob das Element gefunden 
wurde oder nicht. Bei 1025 Elementen sind es 11 bis 12 Vergleiche, also ist log 2 (n) +1 eine 
obere Schranke für die Anzahl der Vergleiche. Bei der sequentiellen Suche würde man für die 
gleiche Feldgröße durchschnittlich 512 Vergleiche benötigen; das entspricht etwa einem Fak¬ 
tor von 50! Dieser Faktor (sequentielles Suchen/binäres Suchen) wächst mit der Zahl der 
Feldelemente. 

Nicht verschwiegen werden soll dabei der (zeitliche) Aufwand für das Sortieren des Feldes. 
Bezeichnen wir diesen mit F, den Aufwand für das binäre Suchen mit B und den für das 
sequentielle Suchen mit S, so lohnt sich das Sortieren des Feldes wenn gilt 

m*S>m*B + F 

wobei m die Zahl der zu erwartenden Suchvorgänge ist. Diese Ungleichung ist jedoch recht oft 
erfüllt. Man schätzt, daß über ein Viertel der gesamten Rechenzeit aller Computer für Sortier¬ 
vorgänge verwendet wird. 

Wir wenden uns im folgenden dem Sortieren von Feldern zu und beschreiben zwei Algorith¬ 
men; zunächst einen einfachen (und langsamen), dann einen komplizierteren (und schnellen). 
Ein Sortieralgorithmus soll aus einem unsortierten Feld ein sortiertes erstellen. Ein Feld sei 
sortiert, wenn gilt: 

feld[i]. schluessel^feld[j].schluessel für alle i<j. 

Einfaches Sortieren durch Austauschen 

Das Verfahren ist ganz einfach: man durchsucht das Feld nach dem kleinsten Element und 
bringt es durch Vertauschen an die erste Stelle (mit Index 0). An die zweite Stelle soll das zweit¬ 
kleinste Element; also durchsuchen wir das restliche Feld (vom Index 1 an) nach dem kleinsten 
Element und bringen es dorthin. So fahren wir fort, bis wir alle Stellen richtig belegt haben. 
Das realisieren wir mit zwei FOR-Schleifen (die äußere bestimmt die Stelle für das jeweilig 
kleinste Element, welches mit der inneren gesucht wird): 

PROCEDURE sortiere; 

VAR i,j,minimum: CARDINAL; 

BEGIN 

FOR i := 0 TO max-1 DO 
minimum : = i; 

FOR j := i + 1 TO max DO 

IF feld[j].schluessel < feld[minimum]. schluessel 
THEN minimum := j END 

END; 
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vertausche(feld[i],feldfminimum]) 
END 

END sortiere; 


Es bleibt nur noch die Prozedur vertausche zu erklären. Man vertauscht zwei Variablen 
einfach mittels Zuweisungen über einen Zwischenspeicher hilf: 

PROCEDURE vertausche (VAR a,b: verbünd); 

VAR hilf: verbünd; 

BEGIN 

hilf := a; a := b; b := hilf 
END vertausche; 


Statt des Prozeduraufrufs von vertausche in der Prozedur sortiere läßt sich selbstver¬ 
ständlich das Vertauschen auch explizit formulieren: 

hilf : = feld[i]; feld[i] := f eld[mininium j; feld[minimum] := hilf; 

hilf ist dann in sortiere zu deklarieren. Durch den entfallenen Prozeduraufruf erreicht 
man eine höhere Geschwindigkeit. 

Falls der Verbund aber sehr groß ist (unser eingangs erwähnter Kundentyp belegt 104 Byte), 
ist der obige Austausch etwas langsam, da bei der Ausführung insgesamt 3 x 104 Byte (=312 
Byte) zugewiesen werden. In diesem Falle empfiehlt es sich, das Austauschen der Byte von ei¬ 
ner Prozedur auf Assembler-Ebene ohne Benutzung eines Hilfsspeichers vornehmen zu las¬ 
sen. Wie man so was schreibt, zeigen wir ausführlich im Kapitel 3. In Megamax-Modula ist 
eine solche Prozedur unter dem Namen SwapVar im Modul SysUti 10 schon vorhanden; der 
Megamax-Programmierer schreibt also in der 10. Zeile: 

SwapVar(feld[i], feld[minimum]); 

Wenn das zu sortierende Feld sehr viele Elemente hat, wird das obige Sortierverfahren sehr 
langsam. Die innere Schleife wird von der äußeren max-mal aufgerufen mit jeweils 1 bis max 
Vergleichen. Das macht insgesamt 

max + (max-1) + (max-2) + ... +2+1= max (max+1) 

2 
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Vergleiche. Die Anzahl der Vergleiche wächst also quadratisch mit der Anzahl der Feldkom¬ 
ponenten; man sagt, der Aufwand ist von der Ordnung 0(n 2 ) (großer Buchstabe »O«, keine 
Null!). Das ist (leider) bei allen einfachen Sortierverfahren der Fall. Darum führen wir hier 
nicht weitere mehr oder weniger triviale Sortieralgorithmen auf (wie in vielen Informatikbü¬ 
chern als Seitenfüller üblich), sondern erklären gleich den stets bei großen Feldern angewand¬ 
ten Algorithmus »Quicksort«. Quicksort ist ein auf C.Ä.R. Hoare zurückgehendes Verfahren 
mit einem Aufwand der Ordnung 0(n*log 2 (n)). 

Schnelles Sortieren eines Feldes (Quicksort) 

Zur Erläuterung ist es hilfreich, sich vorzustellen, wie man selbst größere »Datenmengen« 
(z.B. in Form von Karteikarten) sortieren würde. Nehmen wir mal an, wir hätten einen Stapel 
mit rund 1000 Adreßkarten (unsere Kundenkartei) vor uns und kämen auf die Idee, diese zu 
sortieren. Nun, 1000 Karten sind sicherlich zu viel, als daß man sie mal eben »aus der Hand« 
sortieren kann. Also nimmt man erst mal eine »Grobsortierung« vor: man verteilt die Karten 
auf mehrere Gruppen (A-E, F-J,oder einfach nach Anfangsbuchstaben). Diese kann man 
dann getrennt sortieren (falls diese dazu immer noch zu groß sind, kann man sie - jede für 
sich - wieder »grobsortieren« usw. Spätestens wenn man nur noch zwei Karten in der Hand 
hat, dürfte es keine Probleme mehr geben...). Danach muß man die Grüppchen nur noch Zu¬ 
sammenlegen und der Stapel ist sortiert. 

Genauso arbeitet auch Quicksort. Hier wird das Feld bezüglich eines mittleren Elementes x in 
zwei Teilfelder zerlegt, so daß die Elemente im ersten Teilfeld kleiner als x sind, die im anderen 
größer. Als x nimmt man irgendein Element aus dem (noch ungeteilten) Feld, im einfachsten 
Fall das erste. Das »Zerlegen« eines Teilfeldes geschieht durch Umverteilen der Elemente; 
dazu sucht man von links das erste Element, das größer ist als x und von rechts das erste klei¬ 
nere (dies geschieht in der Prozedur in den beiden innersten WHILE-Schleifen) und tauscht 
dann die beiden Elemente. Das wiederholt man, bis links alle kleineren und rechts alle größe¬ 
ren als x stehen (die beiden Hälften können ungleich groß sein, schlimmstenfalls besteht eine 
Hälfte nur aus einem Element - dem x). Die beiden kleineren Teile werden dann wieder ge¬ 
trennt sortiert - das geschieht, indem Quicksort sich einfach rekursiv aufruft - bis ein Teilfeld 
nur noch aus einem Element besteht. Dieses ist dann zwangsläufig sortiert: 
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PROCEDURE QuickSort(links,rechts: CARDINAL); 

VAR a,b: CARDINAL; 

mittlerer: CARDINAL; 

BEGIN 

a := links; b := rechts; 

mittlerer := feld[(a+b) DIV 2].schluessel; 

REPEAT 

WHILE feldfa].schluessel < mittlerer DO INC(a) END; 

WHILE feld[b].schluessel > mittlerer DO DEC(b) END; 

IE a <= b THEN 

vertausche(feldfa],feld[b]); 

INC(a); DEC(b) 

END; 

UNTIL a > b; 

IP links < b THEN QuickSort(links, b) END; 

IE a < rechts THEN QuickSort(a,rechts) END; 

END QuickSort; 

Als Vergleichselement für das Zerlegen wird hier das Element in der Feldmitte ausgewählt. 
Wenn dies zufällig auch größenmäßig zumeist das mittlere Element ist, so zeigt die Theorie, 
daß n*log 2 (n)-Vergleiche und n*log 2 (n)/6-Austauschoperationen nötig sind. Das Schlimm¬ 
ste was passieren kann, ist, daß das »mittlere Element« immer das größte (oder kleinste) Ele¬ 
ment des Teilfeldes ist. Dann besteht das eine Teilfeld aus einem Element, das andere aus n-1 
Elementen. Damit wird der Aufwand wieder von der Ordnung 0(n 2 ). Dieser Extremfall 
kommt in der Praxis selten vor, so daß man Quicksort als Verfahren der Ordnung 
0(n*log 2 (n)) einstuft. Er tritt auf, wenn man als »mittleres Element« einfach immer das 
erste von jedem Teilfeld nimmt und das Feld vorher schon sortiert oder in großen Teilen sor¬ 
tiert war. Dann ist nämlich das erste Element immer das kleinste. 

Zwischen n*log 2 (n) und n 2 liegt insbesondere bei großen nein beachtlicher Unterschied, den 
man den Formeln nicht sofort ansieht. Dazu zeigen wir folgende Grafik, die auf gemessenen 
Laufzeiten (siehe Zahlenmaterial am Kapitelende) basiert. 
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Bild 2.1: Algorithmen der Ordnung ö(n 2 ) und 0(n log n) 

Sortieren durch Austauschen ist nur für sehr kleine n (etwa n<5) dem Quicksort-Algo¬ 
rithmus überlegen, da hier der Aufwand für die Zerlegung in Teilfelder und die damit verbun¬ 
denen Prozeduraufrufe (bei der Rekursion) unverhältnismäßig groß sind. Wir nehmen dies 
zum Anlaß, Quicksort zu verbessern. 

Optimierter Quicksort-Algorithmus und der externe Modul »Felder« 

Folgende Tricks werden zur Beschleunigung vorgenommen: 

1. Wenn die Feldlänge der zu sortierenden Teilfelder unter 5 sinkt, rufen wir nicht mehr 
QuickSort, sondern das einfache sortiere auf. 

2. Bei einem Feldzugriff wie feld[a] muß jeweils eine Multiplikation durchgeführt wer¬ 
den, denn die Adresse von feld[a] wird aus der Basisadresse feld[0] + a 
*TSIZE (FeldElementTyp ) errechnet. Bei den beiden WHILE-Schleifen wird das Feld 
jedoch nur sequentiell durchlaufen, d. h. die Adressen werden nur um TSIZE(FeldEle- 
mentTyp) höher bzw. niedriger gesetzt. Wir nutzen dies aus, indem wir zwei Zeiger pa 
und pb, die auf feld[a] und feld[b] zeigen, jeweils erhöhen bzw. erniedrigen. Eine 
Addition bzw. Subtraktion ist schneller als eine Multiplikation. 
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Quicksort soll aber nicht nur geschwindigkeitsmäßig »getuned« werden. Eine weitere Ziel¬ 
setzung ist die Schaffung eines allgemein verwendbaren Moduls Felder, der die Prozedu¬ 
ren QuickSort und binaerSuche zusammenfaßt. Dieser Modul soll unabhängig vom 
zu sortierenden Feldtyp sowie von den Feldgrenzen sein. Mit dieser Flexibilität kann man 
u.a. in einem Programm zwei verschiedene Felder mit verschiedenen Vergleichsprozedu¬ 
ren behandeln, z. B. Kunden (Schlüssel ist die Kundennummer vom Typ CARDINAL) 
und Artikel (Schlüssel ist die Artikelbezeichnung vom Typ String). Dazu sind folgende 
Änderungen nötig: 

3. In der Parameterliste muß dann die Basisadresse des Feldes, die Anzahl der zu sortieren¬ 
den Feldelemente sowie die Größe einer Feldkomponente in Bytes übergeben werden. 

4. Die »kleiner«-Relation für die Schlüsselvergleiche muß vom aufrufenden Modul bereitge¬ 
stellt werden, da sie sich explizit auf den jeweiligen Datentyp des Feldes bezieht. 

5. Quicksort ruft sich zweimal selbst auf. Um das zeitaufwendige Kopieren der nunmehr 
recht langen Parameterliste bei der Rekursion zu vermeiden, wird das eigentliche Sortieren 
in einer lokalen Prozedur qSort mit einer minimalen Parameterliste abgehandelt. Au¬ 
ßerdem sorgen wir dafür, daß der Rekursionsstack nicht überläuft, in dem zunächst immer 
das kleinere der beiden Teilfelder weiterbehandelt wird. 

6. Da der Modul typenunabhängig arbeiten soll, kann man sich in der Vertauschprozedur 
nicht auf einen bestimmten Typ festlegen. Deshalb verwenden wir die universelle (und 
schnelle) Prozedur SwapN aus dem Modul LowLevel, der im Kapitel 3 beschrieben wird. 
Deshalb ist LowLevel vor Felder zu kompilieren. 

7. Auch für die Zwischenspeicherung des Vergleichselementes feld[ (a+ b)DlV2] müs¬ 
sen wir einen Trick an wenden, da unserem Modul dessen Datentyp nicht bekannt ist. Wir 
kopieren hierzu diese Variable byteweise mit der Prozedur CopyN aus dem Modul Low¬ 
Level auf den Heap. Hierzu muß zunächst der nötige Speicherplatz anfangs reserviert 
und nach Beendigung des Sortierens wieder freigegeben werden. Dies ist neben dem Aufruf der 
lokalen Prozedur qSort die einzige Aufgabe der übergeordneten Prozedur QuickSort. 

DEFINITION MODULE Felder; 

FROM SYSTEM IMPORT ADDRESS; 

TYPE 

kleinerProzedur = PROCEDURE(ADDRESS,ADDRESS): BOOLEAN; 

PROCEDURE QuickSort( 

FeldAddresse : ADDRESS; (* Basisadresse des zu sort. Feldes *) 

Anzahl : CARDINAL; (* Zahl der zu sortierenden Elemente *) 
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groesse : LONGCARD; (* Anz. d. Bytes einer Feldkomponente *) 

kleiner : kleinerProzedur); (* Vergleichsproz. für die Schlüssel *) 


PROCEDURE binaerSuche( 

FeldAddresse : ADDRESS; 

pGesucht : ADDRESS; (* Adresse des gesuchten Schlüssels *) 
links,rechts : CARDINAL; 
groesse : LONGCARD; 

kleiner : kleinerProzedur): CARDINAL; 

(* 

* Rückgabewert ist der entsprechende Feldindex, wenn der 

* Schlüssel gefunden wurde, andernfalls 5 rechts + 1’ 

*) 

END Felder. 


Die Prozeduren CopyN und SwapN importieren wir aus Geschwindigkeitsgründen aus dem 
Maschinensprache-Modul LowLevel. Natürlich kann man sie auch durch eine reine 
Modula-Version ersetzten: 

PROCEDURE CopyN(von, nach : ADDRESS; groesse : LONGCARD); 

VAR i: LONGCARD; 

pVon, pNach: POINTER TO BYTE; 

BEGIN 

pVon := von; pNach := nach; 

FOR i := ID TO groesse DO 
pNach" := pVon"; 

INC(pNach); INC(pVon) 

END 

END CopyN; 

PROCEDURE SwapN(adrl, adr2 : ADDRESS; groesse : LONGCARD); 

VAR i : LONGCARD; 

hilf : BYTE; 
pl, p2 : POINTER TO BYTE; 

BEGIN 

pl := adrl; p2 : = adr2; 

FOR i :» ID TO groesse DO 

hilf := p2~; p2" : = pl"; p2" := hilf; 

INC(pl); INC(p2) 

END 

END SwapN; 
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Damit kann im Implementationsmodul der Import von LowLevel entfallen, allerdings ist der 
Datentyp BYTE aus SYSTEM zu importieren. 

IMPLEMENTATION MODULE Felder; 

FROM SYSTEM IMPORT ADDRESS; 

FROM Storage IMPORT ALLOCATE, DEALLOCATE; 

FROM LowLevel IMPORT CopyN, SwapN; 

PROCEDURE QuickSort( 

FeldAdresse : ADDRESS; 

Anzahl : CARDINAL; 

groesse : LONGCARD; 

kleiner : kleinerProzedur); 

VAR pa,pb,pra: ADDRESS; 

PROCEDURE ZeigerElement(i: CARDINAL): ADDRESS; 

BEGIN 

RETURN FeldAdresse + LONG(i) * groesse 
END ZeigerElement; 


* zu lahm! braucht bei 1000 REAL’s 2:12 min: sec! 

PROCEDURE PrimitivSortl (li,re: CARDINAL); 

VAR i,j: CARDINAL; 

pi: ADDRESS; 

BEGIN 

FOR i := li TO re-1 DO 

pi := ZeigerElement(i); 

FOR j := i+ 1 TO re DO 

IF kleiner(ZeigerElement(j), pi) THEN 

SwapN(ZeigerElement(j), pi, groesse) END 

END 

END 

END PrimitivSortl; 

- *) 

(*-bei 1000 REAL’s: 1:35 min: sec-> *) 

PROCEDURE PrimitivSort(li,re: CARDINAL); 

VAR i,j: CARDINAL; 

pmin: ADDRESS; 

BEGIN 

FOR i :> li TO re-1 DO 
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pmin := ZeigerElement(i); 

POR j := i+1 TO re DO 

IP kleiner(ZeigerElement(j), pmin) THEN 
pmin := ZeigerElement(j) END 

END; 

SwapN(ZeigerElement(i), pmin, groesse) 

END 

END PrimitivSort; 


0 


PROCEDURE qSort(li,re: CARDINAL); 

VAR a,b: CARDINAL; 

BEGIN 

IP re-li < 4 THEN (* ab 4 Elementen lohnt sich PrimitivSort! *) 

PrimitivSort(li, re) 

ELSE 

a : - li; b : = re; 

CopyN(ZeigerElement((li+re) DIV 2), pm, groesse); 
pa ZeigerElement(a); 
pb := ZeigerElement(b); 

REPEAT 

WHILE kleiner(pa,pm) DO INC(a); INC(pa,groesse) END; 

WHILE kleiner(pm,pb) DO DEC(b); DEC(pb,groesse) END; 

IP a <= b THEN 

SwapN(pa,pb,groesse); 

INC(a); INC(pa,groesse); 

DEC(b); DEC(pb,groesse) END 
UNTIL a > b; 

IP b-li < re-a THEN (* zuerst kleineres Feld sortieren *) 

IP li < b THEN qSort(li,b) END; 

IP a < re THEN qSort(a,re) END 

ELSE 

IF a < re THEN qSort(a,re) END; 

IP li < b THEN qSort(li,b) END 

END 

END 

END qSort; 


BEGIN (* QuickSort *) 

ALLOCATE(pm,groesse); 
qSort(0, Anzahl-1); 
DEALLOCATE(pm, groesse) 
END QuickSort; 
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PROCEDURE binaerSuche( 
FeldAdresse 
pGesucht 
links,rechts 
groesse 
kleiner 


ADDRESS; 

ADDRESS; 

CARDINAL; 

LONGCARD; 

kleinerProzedur): CARDINAL; 


VAR 


m, li, re : CARDINAL; 


PROCEDURE gleich(pl,p2: ADDRESS): BOOLEAN; 

BEGIN 

RETURN NOT (kleiner(pl,p2) OR kleiner(p2,pl)) 


END gleich; 

PROCEDURE ZeigerElement(i: CARDINAL): ADDRESS; 

BEGIN 

RETURN FeldAdresse + LONG(i) * groesse 
END ZeigerElement; 

BEGIN (* binaerSuche *) 

li := 0; re := rechts - links; 

WHILE li < re DO 

m := (li + re) DIV 2; 

IF kleiner (ZeigerElement(m),pGesucht) 

THEN li := m+1 
ELSE re := m 

END 

END; 

IF gleich(pGesucht,ZeigerElement(li)) THEN RETURN links+li; 
ELSE RETURN rechts+1 END 
END binaerSuche; 

END Felder. 


Wir demonstrieren die Verwendung des Moduls Felder zum Sortieren eines Feldes von reel¬ 
len Zahlen: 


MODULE FeldDemo; 

FROM SYSTEM IMPORT ADDRESS, ADR, TSIZE; 

FROM InOut IMPORT Read, WriteCard, WriteFix, WriteLn, WriteString; 
FROM RandomGen IMPORT Randomize, Random; 

FROM Felder IMPORT QuickSort; 
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CONST max = 20; 

TYPE ZeigerTyp = POINTER TO REAL; 

(*--- 

: Die Vergleichsfunktion für REAL-Zahlen 
: Wird der QuickSort-Funktion als Parameter übergehen 
: Kann für jeden Datentyp analog geschrieben werden 

+ -*) 

PROCEDURE realKleiner(a,b: ADDRESS): BOOLEAN; 

VAR pa, pb: ZeigerTyp; 

BEGIN 
pa : = a; 
pb := b; 

RETURN pa~ < pb~ 

END realKleiner; 

(*-—- 

: Druckt ein Feld von REAL-Zahlen beliebiger Länge aus 

+ -— —-*) 

PROCEDURE DruckeFeld(VAR feld: ARRAY OF REAL); 

VAR i: CARDINAL; 

BEGIN 

FOR i := 0 TO HIGH(feld) DO 

WriteLn; WriteCard(i,3); WriteFix(feld[i], 9, 2) 

END; 

WriteLn; 

END DruckeFeld; 

VAR 

UnserFeld 
i 

taste 

BEGIN 

(*- Feld mit Zufallszahlen belegen -*) 

Randomize(1234567); 

FOR i := 1 TO max DO UnserFeld[i] := 100.0 * Random() END; 
DruckeFeld(UnserFeld); (* Feld vor dem Sortieren drucken *) 

QuickSort( ADR(UnserFeld), max, TSIZE(REAL), realKleiner); 
DruckeFeld(UnserFeld); (* Feld ist jetzt sortiert *) 

WriteLn; WriteString("Bitte Taste drücken”); 

Read(taste); 

END FeldDemo. 


ARRAY[1..max] OF REAL; 
CARDINAL; 

CHAR; 
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Die Prozedur realKleiner arbeitet in unserem Beispiel auf reellen Zahlen. In entsprechen¬ 
der Weise läßt eine Boolesche Prozedur kleiner für jeden Datentyp implementieren. Wich¬ 
tig dabei ist folgendes: 

1. kleiner(a,a) = FALSE 

2. Entweder gilt kleiner (a, b) oder kleiner (b, a) 

3. Gilt kleiner(a, b) und kleiner (b,c),so muß auch kleiner(a, c) gelten. 

Als Übung für den Leser schlagen wir vor, ein Feld vom eingangs definierten Kundentyp zu¬ 
nächst nach der Kundennummer und anschließend nach dem Namen zu sortieren, das zuerst 
sortierte Feld in eine weitere Feldvariable zu speichern und so eine Möglichkeit der schnellen 
Suche nach beiden Schlüsseln zu realisieren. 

Wir haben einmal die Laufzeiten für Quicksort und Sortieren durch Auswahl bei unserem 
Modul Felder bei verschiedenen Feldgrößen gemessen. Die Unterschiede sind sehenswert: 
z. B. bei einem Feld von 1000 REAL-Zahlen ist Quicksort ca. 50mal schneller! Die übrigen Er¬ 
gebnisse zeigt die abschließende Tabelle: 


Feldelemente n 

Quicksort 

Sortieren durch Auswahl 

3 

0.0028 s 

0.0026 s 

5 

0.004 s 

0.004 s 

10 

0.009 s 

0.013 s 

31 

0.036 s 

0. 1 s 

100 

0. 17 s 

1. 0 s 

316 

0. 57 s 

9.7 s 

1000 

2. 0 s 

94 s 

3162 

7.8 s 

900 s (= l A Stunde) 

10000 

28. 0 s 

9000 s ( = 2 X A Stunden!) 


Man erkennt, daß die Zeit für das Sortieren mit unserem optimierten Quicksortalgorithmus 
etwa 0. 0002*n*log 2 (n)s und die für das Sortieren durch Austausch etwa 0. 000l*n 2 
Sekunden beträgt, wie es die obige Grafik zeigt. Der Verbesserungsfaktor ist also 
n/(2*log 2 (n) ) und wächst daher stark mit steigender Anzahl der Feldelemente n. 

Der Aufwand hat sich gelohnt: Wir verfügen nun über einen allgemein brauchbaren, schnellen 
Modul, den man für die immer wiederkehrenden Arbeiten mit Feldern lediglich in die eigenen 
Programme zu importieren hat! Mit dieser Philosophie werden in den folgenden Kapiteln 
Module für dynamische Datenstrukturen und für die Dateiverwaltung kreiert. 
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2.2 Verzeigerte Strukturen 

In Abschnitt 1.6.6 haben wir das Zeigerkonzept eingeführt und seine Vorteile benannt. Hier 
geht es nun zur Sache! Ziel dieses Abschnitts ist es, mit drei wichtigen verzeigerten Datenstruk¬ 
turen - Stapel, Schlange und Baum - vertraut zu machen. 

Wir werden hierzu wie im Abschnitt über Felder allgemein verwendbare externe Module 
schreiben, die für alle mögliche Datentypen konkreter Anwendungsfälle funktionieren (Da¬ 
tenabstraktion). Ihre Verwendung wird anschließend in Beispielprogrammen demonstriert. 

2.2.1 Die Datenstruktur »Stapel« 

Man stelle sich einen Stapel - zum Beispiel von Bierkästen - vor. Auf den Stapel kann man nur 
oben einen weiteren Kasten auflegen. Auch das Abnehmen ist nur elementweise von oben her 
möglich, solange bis der Stapel leer ist. Ein Zugriff auf den fünften Kasten in einem Stapel von 
10 Kästen wäre verhängnisvoll, das lassen wir lieber. 

Man hat also immer nur Zugriff auf das zuletzt abgelegte Element. Das Abstapeln wird in um¬ 
gekehrter Reihenfolge erledigt, wie aufgelegt wurde . Man spricht daher vom LIFO-Prinzip 
(Last In - First Out, »zuerst rein - zuletzt raus«). Um solch eine Stapelstruktur in Modula zu 
simulieren, braucht man einen Zeiger, der immer auf das zuletzt abgelegte Element zeigt. Da¬ 
mit weiß man, ab wo man weiter Aufstapeln oder Abnehmen kann, nennen wir diesen Zeiger 
StapelPtr (»Ptr« steht für pointer , = »Zeiger«). 

Wenn noch kein Stapel da ist, setzen wir StapelPtr auf NIL (er zeigt also auf »Nichts«). 
Diese Initialisierung des Stapels erledigt die Prozedur Einrichten. 

Die Prozedur, die bestimmte Objekte (wir abstrahieren nun leider vom anschaulichem Ein¬ 
gangsbeispiel) auf den Stapel legt, nennen wir nicht etwa »Auflegen«, sondern nach altem 
Brauch »Push«. Push muß mit Storage. ALL0CATE Speicher auf dem Heap reservieren und 
StapelPtr aktualisieren. 

Entsprechend wird ein Objekt mit Pull vom Stapel geholt. Hier ist StapelPtr zu erniedri¬ 
gen und der Speicherbereich mit Storage. DEALLOCATE wieder freizugeben. Ein Zugriff mit 
Pull auf einen leeren Stapel wäre fatal, man würde in Undefinierte Speicherbereiche greifen. 
Daher deklarieren wir eine Boolesche Funktion leer, die Auskunft gibt, ob der Stapel leer ist. 
Diese vier Prozeduren reichen aus, um einen Stapel (engl, stack) zu verwalten. 

Stapel spielen eine wichtige Rolle beim Kompilierungsvorgang: 

• Als wichtigstes Hilfsmittel ist die Benutzung eines Stapels beim Aufruf von Prozeduren zu 
nennen, weil hierbei die Rücksprungadressen auf einen Stapel (den Hardware-Stack) ab¬ 
gelegt werden. Die Parameter einer Prozedur werden beim Aufruf der Prozedur auf einen 
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Stapel gelegt. Die Prozedur holt sich als erstes diese Parameter (in umgekehrter Reihen¬ 
folge) wieder von diesem Stapel ab. 

• Bei der Bearbeitung von arithmetischen Ausdrücken werden in den Termen von links nach 
rechts die Operanden und Operatoren auf einem Stapel zwischengespeichert, falls sie in der 
hierarchischen Ordnung noch nicht auszuführen sind. 

Unser erstes Beispiel ist etwas bescheidener. Es zeigt die Addition zweier natürlicher Zahlen 
mit beliebig großer Stellenzahl. 

Es werden drei Stapel benötigt: je einer für die beiden Summanden und einer für die Summe. 
Gestapelt werden nur die Ziffern 0 bis 9. Mit der Prozedur ZahlEingeben wird für jeden 
Summanden ein Stapel erzeugt. Die Prozedur Addieren holt anschließend die letzten beiden 
Ziffern des Summanden, addiert diese, spaltet Endziffer und Übertrag ab und speichert die 
Endziffer im Stapel e rgebni s ab. Nun liegen die beiden nächsten Ziffern oben auf den Sum¬ 
mandenstapeln; sie werden abgeholt, zusammen mit dem Übertrag addiert und wie vorher 
weiterbehandelt. Dieser Prozeß läuft so lange ab, bis beide Stapel leer sind. Sollte vorher schon 
einer der beiden Summandenstapel leer sein, weil dieser Summand eine kleinere Stellenzahl 
hatte, so wird Null addiert. Da nun die höchstwertige Ziffer der Summe als letzte abgelegt 
worden ist, gibt ZahlAusgebendie Summe in der richtigen Reihenfolge aus (LIFO-Prinzip). 

StapelPtr zeigt also immer auf die letzte Zif¬ 
fer. Damit die anderen Ziffern auch noch zu¬ 
gänglich sind, muß man die Verzeigerung zum 
nächst tieferem Objekt ebenfalls abspeichern. 

Insgesamt ist also der Verbund 


TYPE 

Knoten = RECORD 

Ziffer: [0. .9]; 
naechster: LIFO 
END; 


zu stapeln. Hierbei ist 


TYPE LIFO = POINTER TO Knoten; 

Zur Erinnerung: solche Vorwärtsreferenzen 
sind bei Zeigerdeklarationen ausnahmsweise erlaubt. Damit die wichtige Datenstruktur des 
Stapels von dem zwar anschaulichen, aber ziemlich unwichtigen Beispiel der Zahlenaddition 
getrennt wird, packen wir im nachfolgenden Listing die vier beschriebenen Stapelprozeduren 
in einen lokalen Modul »Stapel 1« 



Bild 2.2: Stapel mit den Daten »1,2,3,4« 
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MODULE BeliebigLangeZahlen; 

FROM Storage IMPORT ALLOCATE, DEALLOCATE; (* nur für Stapell *) 

FROM InOut IMPORT Read, Write, WriteCard, WriteString, WriteLn; 

TYPE ZifferTyp = [0..9]; 

(* -Lokaler Modul Stapell *) 

MODULE Stapell; 

IMPORT ZifferTyp, ALLOCATE, DEALLOCATE; 

EXPORT LIFO, Einrichten, leer, Push, Pull; 

TYPE LIFO = POINTER TO Knoten; 

Knoten = RECORD 

Ziffer : ZifferTyp; 

naechster : LIFO 

END; 

PROCEDURE Einrichten(VAR StapelPtr : LIFO); 

BEGIN 

StapelPtr : = NIL 
END Einrichten; 

PROCEDURE leer(StapelPtr: LIFO) : BOOLEAN; 

BEGIN 

RETURN StapelPtr = NIL 
END leer; 

PROCEDURE Push(VAR StapelPtr : LIFO; z : ZifferTyp); 

VAR p : LIFO; 

BEGIN 

ALLOCATE(p, SIZE(p~)); 

p~.Ziffer := z; 

p~.naechster := StapelPtr; 

StapelPtr : = p; 

END Push; 

PROCEDURE Pull(VAR StapelPtr : LIFO; VAR z : ZifferTyp); 

VAR p ; LIFO; 

BEGIN 

IF NOT leer(StapelPtr) THEN 
z := StapelPtr". Ziffer; 
p := StapelPtr".naechster; 
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DEALLOCATE(StapelPtr,SIZE(StapelPtr^)); 

StapelPtr := p 
END; 

END Pull; 

END Stapell; 

(*---*) 

PROCEDÜRE ZahlEingeben(VAR zahl : LIPO); 

VAR ch : CHAR; 

BEGIN 

Einrichten(zahl); 

LOOP 

Read(ch); 

CASE ch OP 

15C : EXIT | 

”0”..”9” : Push(zahl,ORD(ch) - 0RD(”0”)); 

ELSE Write(7C) END; 

END 

END ZahlEingeben; 

PROCEDÜRE ZahlAusgeben(zahl : LIPO); 

VAR Ziffer : ZifferTyp; 

BEGIN 

WHILE NOT leer(zahl) DO 
Pull(zahl,Ziffer); 

WriteCard(Ziffer,1) 

END 

END ZahlAusgeben; 

PROCEDÜRE Addieren(zahll, zahl2 : LIPO; VAR summe : LIPO); 

VAR zifferl, ziffer2, Ziffer, uebertrag : ZifferTyp; 

hilf : CARDINAL; 

BEGIN 

Einrichten(summe); 
uebertrag := 0; 

WHILE NOT (leer(zahll) & leer(zahl2)) DO 

IP leer(zahll) THEN zifferl := 0 ELSE Pull(zahll,zifferl) END; 

IF leer(zahl2) THEN ziffer2 := 0 ELSE Pull(zah!2,ziffer2) END; 

hilf := zifferl + ziffer2 + uebertrag; 

Ziffer : = hilf MOD 10; 
uebertrag := hilf DIV 10; 

Push(summe,Ziffer) 

END; 
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IF uebertrag > 0 THEN Push(summe,uebertrag) END 
END Addieren; 

VAR summandl,summandS,ergebnis : LIFO; 
antwort : CHAR; 

BEGIN (* BeliebigLangeZahlen *) 

WriteLn; WriteString("Demonstration eines Stapels ”); 
WriteString(”am Beispiel der Addition von langen Zahlen”); WriteLn; 
REPEAT 


WriteLn; WriteString(”1. Zahl (>0, Länge beliebig): ”); 
ZahlEingeben(summandl); 

WriteLn; WriteString(”2. Zahl (>0, Länge beliebig): ”); 
ZahlEingeben(summand2); 

Addieren(summandl,summand2,ergebnis); 

WriteLn; WriteString(”Die Summe beträgt : ”); 

ZahlAusgeben(ergebnis); 

WriteLn; WriteLn; WriteString(”Noch einmal (j/n) ? ”); 
Read(antwort); antwort := CAP(antwort) 

UNTIL antwort = ”N” 

END BeliebigLangeZahlen. 


Der externe Modul »Stapel« 

Wie man an unserem Beispielprogramm erkennt, ist die Programmierung und Handhabung 
eines Stapels recht einfach. 

Leider ist unser lokaler Modul Stapell noch nicht allgemein brauchbar. Für die abgespei¬ 
cherten Inhalte sind hier nur die Ziffern 0 bis 9 zugelassen (vgl. Deklaration von LIFO). 

Durch folgenden Kunstgriff erreichen wir es nun, diese Typabhängigkeit zu durchbrechen: 
Wir stapeln gar nicht mehr die eigentlichen Daten auf, sondern nur noch die Zeiger auf ihre 
Adresse! Die Daten selbst werden an anderer Stelle auf den Heap gelegt. 

Beim Abholen der Daten findet man auf dem Stapel also deren Adresse. Da beliebige Daten¬ 
typen zugelassen sind, benötigt man aber noch eine Information über die Anzahl der Bytes ei¬ 
ner abgespeicherten Variable. Diesen Wert muß man also ebenfalls mit auf den Stapel geben. 
Alle Informationen speichern wir in einem Verbund auf dem Stapel: 
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TYPE 

LIPO = POINTER TO Kopf; 

Kopf = RECORD 

ByteZahl : CARDINAL; 
Eintrag : ADDRESS; 
naechster: LIPO 
END; 


Da beim Abspeichern sowohl eines Stapelob¬ 
jekts als auch der eigentlichen Daten der Heap in 
der Reihenfolge von unten nach oben wächst, 
ergibt sich nach zweimaligem Push von Daten 
das nebenstehende Bild 

Die in der Zeichnung markierten Teile gehören 
zur Stapelverwaltung: sie bilden den Kopf, der 
für jeden Datensatz mitangelegt wird. Den Rest 
bilden die eigentlichen Daten, die jeweils über 
den headern (»Köpfen«) liegen. Man erkennt, 
daß mit dem Fortschritt der Allgemeinnützig¬ 
keit der Verwaltungsaufwand steigt (hier gibt es 
Parallelen zu anderen Verwaltungen). 

Die neue Prozedur Push muß nun zweimal 
Speicherplatz anfordern: einmal für den Kopf 
und zum anderen für die eigentlichen Daten. 

Ebenso wird in Pull zweimal Speicherplatz 
freigegeben. 

Wir formulieren nun einen externen Modul Stapel. Die bisher geschilderten Einzelheiten 
sind nur wichtig zum Verständnis des Implementationsmoduls. Der Programmierer, der aber 
beim Gebrauch des Moduls andere Probleme im Kopf hat, muß von diesen Einzelheiten entla¬ 
stet werden. Er braucht nicht zu wissen, wie die Abspeicherung vor sich geht (»Geheimnis¬ 
prinzip«). Ja, er braucht nicht einmal zu wissen, mit welchen Datenstrukturen dies 
im einzelnen realisiert wird. Krasser gesagt, das geht ihn überhaupt nichts an! Also verbergen 
wir nicht nur die Implementierung der Prozedur im Implementationsmodul, sondern auch 
noch den zugrunde liegenden Datentyp lipo durch einen »opaken« Export. 


Stapel Ptr 


Eintrag 


Bytezahl 


Eintrag 


Bytezahl 


Bild 2.3: Heap mit zwei Daten 
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Wir geben dem Programmierer über das Definitionsmodul also einen Datentyp: 

TYPE LIPO; 

und einen Satz Prozeduren zur Verfügung, die es ihm gestattet, damit umzugehen. Mehr 
braucht er nicht. Er sieht so genau, was er benutzen kann, und es besteht keine Gefahr, daß er 
durch unvorsichtiges hantieren mit diesem Datentyp die komplizierte Datenstruktur »Stapel« 
zerstört, weil er auf die empfindlichen Elemente (wie die Verwaltungszeiger) nicht zugreifen 
kann. Außerdem bleibt der Definitionsmodul so schön übersichtlich. Im Implementations¬ 
modul muß sich natürlich die vollständige Deklaration befinden. 

Einen solchen Modul nennt man einen »abstrakten Datentyp« (ADT). Wir finden unsere ein¬ 
gangs beschriebenen Prozeduren wieder: 

DEFINITION MODULE Stapel; (* ADT = Abstrakter Datentyp *) 

PROM SYSTEM IMPORT BYTE; 

TYPE LIPO; (* Opaker Export *) 

PROCEDURE Einrichten(VAR StapelPtr : LIPO); 

(* 

* Richtet einen leeren Stapel ein, auf den "StapelPtr” zeigt. 

*) 

PROCEDURE leer(StapelPtr: LIPO) : BOOLEAN; 

(* 

* Ergibt TRUE, wenn der Stapel leer ist. 

*) 

PROCEDURE Push(VAR StapelPtr : LIPO; inhalt : ARRAY OP BYTE); 

(* 

* Legt *inhalt* auf den Stapel. 

*.) 

PROCEDURE Pull(VAR StapelPtr : LIPO; VAR inhalt : ARRAY OP BYTE); 

(* 

* Holt *inhalt* vom Stapel. 

* Der Stapel darf nicht leer sein (voher mit *leer* testen). 

* Die Variable ’inhalt* muß dieselbe Bytezahl wie bei ’Push’ 

* haben. 

*) 

END Stapel. 
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Zur Implementation ist bereits alles Nötige gesagt worden. Interessant dürfte auch noch die 
Prozedur CopyN sein, die Variablen beliebigen Typs und beliebiger Größe kopiert. Im Ge¬ 
gensatz zum vorigen Abschnitt, wo hierfür auf den Assemblersprachen-Modul LowLevel 
zurückgegriffen wurde, stellen wir hier eine Version vor, die voll in Modula geschrieben ist. 

IMPLEMENTATION MODULE Stapel; 

PROM SYSTEM IMPORT BYTE, ADR, ADDRESS; 

PROM Storage IMPORT ALLOCATE, DEALLOCATE; 

TYPE LIPO = POINTER TO köpf; 

köpf = RECORD 

ByteZahl : CARDINAL; 

Eintrag : ADDRESS; 
naechster : LIPO 
END; 

PROCEDÜRE Einrichten(VAR StapelPtr : LIPO); 

BECIN 

StapelPtr : = NIL 
END Einrichten; 

PROCEDÜRE leer(StapelPtr: LIPO) : BOOLEAN; 

BEGIN 

RETURN (StapelPtr = NIL) 

END leer; 

PROCEDÜRE CopyN(von, nach : ADDRESS; groesse : CARDINAL); 

VAR i : CARDINAL; 

pVon, pNach : POINTER TO BYTE; 

BEGIN 

pVon := von; pNach := nach; 

POR i := 1 TO groesse DO 
pNach'“ := pVon~; 

INC(pNach); INC(pVon) 

END 

END CopyN; 

PROCEDÜRE Push(VAR StapelPtr * LIFO; inhalt : ARRAY OF BYTE); 

VAR 

i,anz : CARDINAL; 

p : LIFO; 

BEGIN 

anz:=HIGH(inhalt); 
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ALLOCATE(p,SIZE(p~)); 

WITH p* DO 

ByteZahl:=anz; 

ALLOCATE(Eintrag,LONG(anz + 1)); 

CopyN(ADR(inhalt),Eintrag, anz + 1); 
naechster:=StapelPtr 
END; 

StapelPtr:=p 
END Push; 

PROCEDURE Pull(VAR StapelPtr : LIPO; VAR inhalt : ARRAY OP BYTE); 
VAR i,anz : CARDINAL; 

p : LIPO; 

BEGIN 

anz: =HIGH( inhalt); 

IP leer(StapelPtr) OR (StapelPtr~. ByteZahl # anz) THEN HALT END; 
p:=StapelPtr; 

WITH p~ DO 

StapelPtr:^naechster; 

CopyN(Eintrag, ADR(inhalt),anz + 1); 

DEALLOCATE(Eintrag,LONG(anz+ 1)) 

END; 

DEALLOCATE(p,SIZE(p ~)) 

END Pull; 

END Stapel. 


Anwendung des externen Moduls »Stapel« 

In einem kleinem Beispiel soll nun demonstriert werden, wie man mit dem externen Modul 
Stapel umgeht. 

Wie bereits erwähnt, werden Stapel beim Abarbeiten rekursiver Prozeduren verwendet. Der 
Programmierer kann nun auch selber rekursive Prozeduren iterativ formulieren, indem er 
zum Ablegen der Parameter einen Stapel benutzt. Wenigstens auf diese Art läßt sich jede re¬ 
kursive Prozedur in eine iterative umschreiben. Dieses Verfahren wird in dem folgenden Pro¬ 
gramm am Beispiel der schon bekannten Prozedur QuickSort demonstriert. 

Die Prozedur push2 speichert die beiden Feldgrenzen auf einen Stapel, pull2 holt sie dort 
wieder ab. Die Prozedur Quicksort selbst wird nur geringfügig verändert (vergleichen Sie 
mit der ersten Version). Zur Demonstration des Algorithmus wird ein Feld von 100 Zufalls¬ 
zahlen sortiert. 
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MODULE StapelDemoMitQuickSortIterativ; 

IMPORT Stapel; 

PROM InOut IMPORT Read, WriteCard, Write-String, WriteLn; 

PROM RandomGen IMPORT RandomCard, Randomize; 

CONST raax = 100; 

TYPE DoppelWort = RECORD il,i2 : CARDINAL END; 

VAR feld : ARRAY [1..max] OP CARDINAL; 

oben : Stapel.LIPO; 

PROCEDURE push2(a, b : CARDINAL); 

VAR doppel : DoppelWort; 

BEGIN 

doppel.il := a; doppel.i2 := b; Stapel.Push(oben,doppel) 

END push2; 

PROCEDURE pull2(VAR a,b : CARDINAL); 

VAR doppel : DoppelWort; 

BEGIN 

Stapel.Pull(oben,doppel); a := doppel.il; b := doppel.i2 
END pull2; 

PROCEDURE QuickSortIterativ(links,rechts : CARDINAL); 

VAR 

a, b : CARDINAL; 

mittlerer,hilf : CARDINAL; 

BEGIN 

Stapel. Einrichten(oben); 
push2(links,rechts); 

REPEAT 

pull2(links, rechts); 
a := links; b := rechts; 
mittlerer := feld[(a + b) DIV 2]; 

REPEAT 

WHILE feld[a] < mittlerer DO INC(a) END; 

WHILE feld[b] > mittlerer DO DEC(b) END; 

IF a <= b THEN 

hilf := feld[a]; feld[a] := feld[b]; feld[b] := hilf; 
INC(a); DEC(b) 

END; 

UNTIL a > b; 
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IF links < b THEN push2(links, b) END; 

IF a < rechts THEN push2(a,rechts) END; 

UNTIL Stapel.leer(oben) 

END QuickSortlterativ; 

VAR taste : CHAR; 

i : CARDINAL; 

BEGIN 

WriteString(„Unsortiertes Feld:”); WriteLn; 

Randomize(OL); 

FOR i := 1 TO max DO feldfi] := RandomCard(0, 999); WriteCard(feld[i],5) END; 
QuickSortIterativ(l,max); 

WriteLn; WriteString(”Sortiertes Feld:”); WriteLn; 

FOR i := 1 TO max DO WriteCard(feld[i],5) END; 

Read(taste) 

END StapelDemoMitQuickSortlterativ. 


Vielleicht haben Sie Lust, unsere Stoppuhr aus Abschnitt 3.3.1 einzubauen und die Zeiten mit 
denen aus 2.1 zu vergleichen. Man wird erkennen, daß die rekursive Version trotzdem leicht 
schneller ist. Woran das liegt? Nun, bei unserer »gewaltsamen« Iteration von Quicksort geht 
an einigen Stellen Zeit verloren: Wo in der rekursiven Version der Selbstaufruf steht, sind in 
der iterativen Prozedur die Funktionen push2 und pull2. Diese rufen wiederum 
Stapel. Push und Stapel. Pull auf. Und auch dort tut sich einiges; unter anderem rufen 
sie jeweils gleich zweimal Storage. ALLOCATE und Storage. DEALLOCATE auf, und diese 
brauchen schließlich auch ihre Zeit. 

Es dürfte klar geworden sein, daß mit dem Modul Stapel jeder Datentyp zu behandeln ist. 
Zum Beispiel können in einem Programm zwei unterschiedliche Stapel mit Einträgen ver¬ 
schiedenen Typs bearbeitet werden. Man hat dann zwei Stapelzeiger, die auf die Spitze der je¬ 
weiligen Stapel zeigen. 

Es ist aber auch möglich, in einem Stapel unterschiedliche Datentypen zu speichern, weil wir 
uns die Größe eines jeden Eintrags getrennt merken. Im folgenden Beispiel werden drei 
REAL-Zahlen und drei CARDINAL-Zahlen auf den selben Stapel gelegt. 

MODULE StapelTest; 

IMPORT Stapel; 

FROM InOut IMPORT WriteReal, ReadReal, WriteCard, ReadCard, WriteLn, 

WriteString, KeyPressed; 
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VAR top : Stapel.LIPO; 
x, y, z : REAL; 
i,j,k,1 : CARDINAL; 

BEGIN 

Stapel. Einrichten (top); 

WriteString("Bitte 3 relle Zahlen : ”); WriteLn; 

ReadReal(x); ReadReal(y); ReadReal(z); 

Stapel.Push(top,x); Stapel.Push(top,y); Stapel.Push(top,z); 

WriteString(”Und nun 3 Kardinalzahlen : "); WriteLn; 

ReadCard(i); ReadCard(j); ReadCard(k); 

Stapel.Push(top,i); Stapel.Push(top,j); Stapel.Push(top,k); 

WriteString("Der Stapelinhalt lautet :”); WriteLn; 

POR 1 := 1 TO 3 DO 

Stapel.Pull(top,i); WriteCard(i,10); WriteLn 

END; 

WHILE NOT Stapel.leer(top) DO 

Stapel.Pull(top,x); WriteReal(x,10,5); WriteLn 

END; 

REPEAT UNTIL KeyPressed() 

END StapelTest. 

Nicht erlaubt ist aber das Ablegen einer REAL-Zahl, die man dann mit einer CARDINAL-Varia¬ 
ble abholen will (wie soll die arme Funktion pull auch eine REAL-Zahl in einem 2-Byte- CAR¬ 
DINAL unterbringen?). Einen solchen Programmierfehler bemerkt die Funktion pull und 
reagiert darauf drastisch mit einem Programmabbruch, indem sie HALT aufruft. Je nach Sy¬ 
stem landet man dann im »Debugger« und kann mit seiner Hilfe feststellen, wo man was falsch 
gemacht hat. In einem funktionierenden Programm darf es zu so etwas natürlich nicht kom¬ 
men. Die HALT-Aufrufe in unseren Implementationsmodulen dienen also nur zur Hilfe des 
Programmierers! Sie melden ihm unerlaubte Zugriffe. 


2.2.2 Die Datenstruktur »Schlange« 

Im letzten Abschnitt ging das Abholen der Daten nach dem biblischem Motto »die letzten 
werden die ersten sein«. Bei Warteschlangen hingegen ist die Losung: »wer zuerst kommt, 
mahlt zuerst«. Dieses Prinzip heißt FIFO-Prinzip (First In - First Out, »zuerst rein, zuerst 
raus«). Der geneigte Leser ahnt schon, worauf es hinaus läuft: Es soll ein abstrakter Datentyp 
»Schlange« geschaffen werden, der im großen und ganzen Stapel ähnelt, nur daß neue Da¬ 
ten sich »hinten« an die Schlange anstellen und die Daten von »vorne« abgeholt werden. Dies 
stellt sich so dar: 
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erster letzter 






Bild 2.4: Die Datenstruktur »Schlange« 

Schlangen werden zur Simulation von Warteschlangen benutzt, bei der Bearbeitung mehrerer 
»Jobs« in EDV-Anlagen, bei Tastaturpuffern, bei der Übertragung von Daten aus dem Kern¬ 
speicher an einen Drucker oder ein Modem. 

Zu diesen Zwecken werden aber auch Strukturen von begrenzter Länge wie Arrays und der 
Ringpuffer (der eine »endliche« Lösung einer Schlange darstellt) eingesetzt. So kann der 
Tastaturpuffer voll werden; manche Rechner erzeugen dann bei weiteren Tastendrücken ein 
nervendes Gepiepse. 

Zur Implementation einer Schlange benötigt man wiederum vier Prozeduren. Einrichten 
erzeugt eine leere Schlange mit den Zeigern erster und letzter (Anfang und Ende der 
Schlange). 

Die Boolesche Funktion leer prüft, ob noch Elemente in der Schlange abgespeichert sind. 

Anfuegen fügt ein neues Element hinten an die Schlange an; Abholen arbeitet genau umge¬ 
kehrt: Falls noch ein Element vorhanden ist, wird es geliefert. 

Man erkennt an dieser Erläuterung und der obigen Abbildung, daß die Implementation einer 
Schlange insofern etwas schwieriger als die des Stapels ist, als jeweils zwei Zeiger (ersterund 
letzter) zu manipulieren sind. Da wir beim Stapel einige Erfahrung gesammelt haben, kön¬ 
nen wir ohne große Vorrede auf einen allgemein verwendbaren Modul zusteuern. Trotzdem 
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soll die Anwendung des Moduls Schlange genauso einfach sein wie Stapel; der Program¬ 
mierer, der das Modul nur benutzen will, darf mit solchen Einzelheiten nicht belastet werden. 
Also kommt wieder nur der opake Export in Frage. 

Wir fassen also die Zeiger erster und letzter in einem Verbund FIFOHeader zusammen. 
Dummerweise darf ein opaker Typ nur ein einziger Zeiger sein. Dann exportieren wir halt als 
opaken Typ FIFO einen Zeiger auf diesen Verbund. Der opake Typ FIFO, der nach außen 
schlicht 


TYPE FIFO; (* sonst nix *) 


heißt, sieht also nun so aus: 
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nur dem Implementationsmodul, nicht aber dem Anwender bekannt 
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Bild 2.5: Abstrakter Datentyp »FIFO« 

Die Bequemlichkeit, später nur mit dem Typ FIFO umgehen zu müssen, erkauft man sich also 
durch eine zusätzliche »Indirektion« (= Umweg über einen Zeiger). 
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DEFINITION MODULE Schlange; 

FROM SYSTEM IMPORT BYTE; 

TYPE FIFO; 

PROCEDURE Einrichten(VAR SchlangePtr : FIFO); 

(* 

* Es wird eine leere Schlange eingerichtet, 

* auf die SchlangePtr zeigt. 

*) 

PROCEDURE leer(SchlangePtr: FIFO) : BOOLEAN; 

(* 

* Prüft, oh die Schlange leer ist. 

*) 

PROCEDURE Anfuegen(SchlangePtr : FIFO; inhalt : ARRAY OF BYTE); 

(* 

* Fügt ’inhalt’ an das Ende der Schlange. 

* ’inhalt’ kann von beliebigem Typ sein. 

*) 

PROCEDURE Abholen(SchlangePtr : FIFO; VAR inhalt : ARRAY OF BYTE); 
(* 

* Holt ’inhalt’ vom Kopf der Schlange. 

* Die Schlange darf nicht leer sein (vorher mit ’leer’ 

* testen). Die Variale ’inhalt’ muß dieselbe Bytezahl wie 

* beim Abspeichern mit ’Anfuegen’ haben. 

*) 

END Schlange. 


Die Implementation verläuft analog zu der des Stapels. Wir haben noch eine weitere Prozedur 
checkFif o mit aufgeführt, die wir beim Schreiben des Moduls zur Konsistenzkontrolle be¬ 
nutzt haben. Durch eine solche Prozedur wird eine eventuelle fehlerhafte Verzeigerung wäh¬ 
rend der Entwicklungsphase erkannt. Sind die Zeiger nicht so, wie sie sein sollten, bricht das 
Programm mit HALT an einer entsprechenden Stelle ab. Ohne solche Krücken passiert es beim 
Umgang mit Zeigern oft, daß sich Endlosschleifen oder Zeiger ins »Nirwana« (vorzugsweise 
auf längst freigegebene Speicherbereiche) ergeben, die den Programmierer verzweifelt zur 
Reset-Taste greifen lassen. 
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Aus dem fertigen, getesteten Modul können solche Aufrufe natürlich entfallen; wir haben sie 
zur Demonstration stehen gelassen. 

IMPLEMENTATION MODULE Schlange; 

PROM SYSTEM IMPORT BYTE, ADR, ADDRESS; 

PROM Storage IMPORT ALLOCATE, DEALLOCATE; 

TYPE KopfZeiger = POINTER TO Kopf; 

PIFO = POINTER TO FIFOHeader; 

FIFOHeader = RECORD 

erster, letzter : KopfZeiger; 

END; 

Kopf = RECORD 

ByteZahl : CARDINAL; 

Eintrag : ADDRESS; 
naechster : KopfZeiger 
END; 

(*-*) 

(* --Interne Überprüfung auf Konsistenz, nur zu Testzwecken--*) 

(* -kann gelöscht werden-*) 

PROCEDURE CheckFifo(f:FIFO); 

BEGIN 

IF f = NIL THEN HALT END; 

WITH f" DO 

IF erster = NIL THEN 

IF letzter <> NIL THEN HALT END 

ELSE 

IF letzter = NIL THEN HALT END; 

IF letzter".naechster <> NIL THEN HALT END 

END; 

END 

END CheckFifo; 

(*-*) 

PROCEDURE Einrichten(VAR SchlangePtr : FIFO); 

BEGIN 

ALLOCATE(SchlangePtr,SIZE(SchlangePtr")); 

WITH SchlangePtr" DO 

erster :=NIL; letzter:=NIL 
END 

END Einrichten; 
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PROCEDURE leer(SchlangePtr: FIPO) : BOOLEAN; 

BEGIN 

CheckFifo(SchlangePtr); 

RETURN SchlangePtr".erster=NIL 
END leer; 

PROCEDURE CopyN(von, nach : ADDRESS; groesse : CARDINAL); 

VAR i : CARDINAL; 

pVon, pNach : POINTER TO BYTE; 

BEGIN 

pVon : ss von; pNach : = nach; 

POR i := 1 TO groesse DO 
pNach" := pVon"; 

INC(pNach); INC(pVon) 

END 

END CopyN; 

PROCEDURE Anfuegen(SchlangePtr: PIPO; inhalt : ARRAY OP BYTE); 

VAR 

p : KopfZeiger; 

BEGIN 

CheckPifo(SchlangePtr); 

ALLOCATE(p, SIZE(p")); 

WITH p" DO 

ByteZahl := HIGH(inhalt)+ 1; 

ALLOCATE(Eintrag,LONG(HIGH(inhalt)+ 1)); 

CopyN(ADR(inhalt),Eintrag,HIGH(inhalt) + 1); 
naechster:=NIL; 

END; 

WITH SchlangePtr" DO 

IP leer(SchlangePtr) THEN erster := p; letzter:=p 
ELSE 

letzter".naechster :» p; letzter := p 
END 
END; 

CheckPifo(SchlangePtr) 

END Anfuegen; 

PROCEDURE Abholen(SchlangePtr : PIPO; VAR inhalt : ARRAY OP BYTE); 
VAR 

p : KopfZeiger; 

BEGIN 

CheckPifo(SchlangePtr); 

IP leer(SchlangePtr) THEN HALT END; (* falscher Zugriff *) 
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WITH SchlangePtr~ DO 

IP erster~.ByteZahl # HIGH(inhalt)+1 THEN HALT END; (* falscher Datentyp *) 
p:=erster; 

WITH p Ä DO 

erster:=naechster; 

CopyN(Eintrag,ADR(inhalt), HIGH(inhalt) + 1); 

DEALLOCATE(Eintrag,ByteZahl) 

END; 

DEALLOCATE(p, SIZE(p Ä )); 

IP erster = NIL THEN letzter:=NIL END 
END; 

CheckPifo(SchlangePtr) 

END Abholen; 

END Schlange. 


Die Benutzung des Moduls Schlange verläuft analog zu der von Stapel, weshalb wir hier 
keine Anwendungsbeispiele bis auf ein kleines Demonstrationsprogramm zeigen. 

MODULE SchlangeTest; 

PROM InOut IMPORT Read, Write, WriteLn, WriteString, ReadString; 

PROM Schlange IMPORT PIPO, Einrichten, leer, Abholen, Anfuegen; 

VAR Schlange : PIPO; 

s : ARRAY[0..9] OP CHAR; 

i : CARDINAL; 

c : CHAR; 

BEGIN 

Einrichten(Schlange); 

IP leer(schlänge) THEN WriteString(”Die Schlange ist noch leer!”) END; 

WriteLn; WriteString(”Geben Sie ein paar Namen ein (<RET> = Ende):”); 

WriteLn; 

LOOP 

WriteString(”Name: ”); ReadString(s); 

IP s[0] = OC THEN EXIT END; 

Anfuegen(schlänge,s); 

END; 
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WHILE NOT leer(Schlange) DO 
Abholen(schlänge,s); 

WriteLn; WriteString(s); 

END; 

WriteLn; WriteString(”<Taste>”); Read(c) 
END SchlangeTest. 


Weitere Beispiele für den Aufruf des Moduls Schlange geben die Programme Datei Ver¬ 
waltung im Abschnitt 2.3.2 und das Programm Druck in Abschnitt 4.4. Hier werden Na¬ 
men von zu druckenden Dateien mittels einer »File-selector-box« eingegeben in eine Warte¬ 
schlange gespeichert und anschließend der Reihe nach ausgedruckt. Dies entspricht einer typi¬ 
schen »Schlange«-Anwendung. 


2.2.3 Die Datenstruktur »Baum« 

Stapel und Schlangen sind zwar wichtige Elemente in der Datenverarbeitung, aber hier ent¬ 
scheidet sich die Ablage (und der spätere Zugriff) durch die Reihenfolge des Eintreffen der 
Daten. 

Oft möchte man aber Daten nach einem bestimmten Kriterium »linear« ausdrucken, also 
etwa so sortiert, daß »oben« die kleineren Daten stehen und »unten« die größeren (Beispiel: 
Telefonbuch). Wir greifen also hier wieder einen Problemkreis auf, den wir schon bei Felder in 
Abschnitt 2.1 kennengelernt haben. 

Die Daten haben neben der eigentlichen Information einen Schlüssel, nach dem sie mittels ei¬ 
ner »kleiner-Funktions-Prozedur« sortiert werden können. Dann läßt sich schnell mit bin¬ 
ärem Suchen ein gewünschter Datensatz aus einer großen Datenmenge herausfinden. Nun 
haben Felder aber den Nachteil des statischen: Ein neu ankommender Datensatz, der an der 
richtigen Stelle in einem sortierten Feld abgelegt werden soll, zwingt zum Umkopieren aller 
Feld¬ 
elemente, die »hinter« diesem Datum liegen: 
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Bild 2.6: Einfügen in sortiertes Feld 

In unserem Beispiel müssen die Daten 23, 25, 29,34 »umgeschaufelt« werden. In einem kon¬ 
kreten Anwendungsfall könnten dies mehrere Kbyte sein. 

Das gleiche passiert beim Löschen eines Datensatzes. Hierzu kommt noch der bereits im Ab¬ 
schnitt 1.6.6 erwähnte Nachteil der festen Speicherreservierung für ein Feld: war man bei der 
Deklaration eines Feldes zu sparsam, so kann es beim Auftreten zusätzlicher Daten dazu 
kommen, daß das Feld nicht mehr zur Aufnahme ausreicht. Der rechte Feldindex muß höher 
gesetzt werden; das Programm ist erneut zu kompilieren. Letzteres ist nicht mehr möglich, 
wenn es bereits in Benutzerhand ist. 

Also wählt man die Feldgrenzen gleich übermäßig groß! Das führt aber wieder zur Ver¬ 
schwendung von Speicherplatz, den man vielleicht an anderer Stelle gut gebrauchen könnte. 

Man benötigt also eine Struktur, die die Vorteile eines Feldes mit der gewünschten Dynamik 
vereinigt. Diese Struktur heißt »geordneter binärer Baum mit Rückzeiger«. Ihre Kennzei¬ 
chen: 

• Die Daten liegen geordnet (gemäß einer »kleiner«-Funktion) vor. 

• Man kann einen beliebigen Datensatz effizient einfügen oder löschen (unter Beibehaltung 
der Ordnung). 

• Ein Datensatz mit einem bestimmten Schlüssel läßt sich schnell suchen. 

• Von einem Datensatz ist beliebiges »Weiterblättern« zum Datensatz mit dem nächst grö¬ 
ßeren Schlüssel bzw. Zurückgehen auf den Datensatz mit dem nächst niedrigeren Schlüssel 
möglich. 

• Die Ausnutzung des Speichers ist gut. 
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Da die Implementation mit der vollen Leistungsfähigkeit relativ schwer verständlich ist, wol¬ 
len wir den Leser mit einem kleinem Programm EinfacherBaum in Bäume einführen. 

Es handelt sich um einen Baum, dessen Inhalte nur aus Zeichen (Typ CHAR) bestehen. Das 
folgende Demoprogramm bietet die Möglichkeiten: 

• eine geordnete Folge von Zeichen zum Beispiel 
A, C, E, G, J, R, U 

in eine ausgeglichene Baumstruktur zu überführen. Dies ist die Demonstration der Proze¬ 
dur LinearZuBaum. 

• Man kann sich den Baum auf dem Bildschirm ausdrucken lassen. Hierbei ist allerdings die 
Wurzel links, das heißt der Baum ist um 90° nach links gedreht. 

• Man kann die Bauminhalte der Reihenfolge nach ausgeben lassen, dies ist eine Demon¬ 
stration der Prozedur BaumZuLinear. 

• Einfügen von weiteren Zeichen in den Baum ist möglich, testen Sie das aus und rufen Sie 
anschließend DruckeBaum auf! 

• Die Suche nach einem abgespeicherten Zeichen ist möglich. 

Wir haben also eine komplette Baumstruktur implementiert. Bis auf die Tatsache, daß nur 
Zeichen abgespeichert werden können und eine Prozedur zum Löschen fehlt. 

MODULE EinfacherBaum; 

PROM InOut IMPORT Read, Write, WriteString, WriteLn; 

PROM Storage IMPORT ALLOCATE; 

TYPE KnotenPtr = POINTER TO Knoten; 


Knoten 

= RECORD 



inhalt 

: CHAR; 


links, rechts : 

: KnotenPtr 


END; 



VAR Wurzel : KnotenPtr; 


PROCEDURE Einrichten; 

BEGIN 

Wurzel := NIL 
END Einrichten; 

PROCEDURE Einfuegen(VAR Aktuell : KnotenPtr; inhalt : CHAR); 
BEGIN 



Die Datenstruktur »Baum« 


239 


IF Aktuell = NIL THEN (* Ende gefunden, Einfügen als Blatt *) 

ALLOCATE(Aktuell,SIZE(Aktuell")); 

Aktuell".links := NIL; 

Aktuell".rechts := NIL; 

Aktuell".inhalt := inhalt 

ELSIF inhalt < Aktuellinhalt THEN Einfuegen(Aktuell". links,inhalt) 

ELSE Einfuegen(Aktuell".rechts,inhalt) END 
END Einfuegen; 

PROCEDURE Suchen(VAR anfang : KnotenPtr; ziel : CHAR); 

BEGIN 

LOOP 

IF anfang = NIL THEN EXIT END; 

IF anfang". inhalt = ziel THEN EXIT END; 

IF anfang".inhalt < ziel THEN anfang := anfang".rechts 
ELSE anfang := anfang".links END 

END 

END Suchen; 

PROCEDURE DruckeBaura(Aktuell : KnotenPtr; stelle : CARDINAL); 

VAR i : CARDINAL; 

BEGIN 

IF Aktuell # NIL THEN 
WITH Aktuell" DO 

DruckeBaum(rechts, stelle + 1); 

FOR i := 1 TO stelle DO WriteString(” ”) END; 

WriteString(->”); Write(inhalt); WriteLn; 

DruckeBaum(links, stelle + 1); 

END 

END 

END DruckeBaum; 

PROCEDURE BaumZuLinear(Anfang : KnotenPtr); 

BEGIN 

IF Anfang # NIL THEN 

BaumZuLinear(Anfang".links); 

Write(Anfang".inhalt); Write(” ”); 

BaumZuLinear(Anfang". rechts) 

END 

END BaumZuLinear; 

PROCEDURE LinearZuBaum(ElementZahl : CARDINAL; VAR Anfang : KnotenPtr); 

BEGIN 

IF Elementzahl = 0 THEN Anfang := NIL ELSE 
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ALLOCATE(Anfang,SIZE(Anfang")); 

LinearZuBaura(Elementzahl DIV 2, Anfang".links); 

Read(Anfang" . inhalt); Write(” ”); 

LinearZuBaum(Elementzahl - 1 - Elementzahl DIV 2, Anfang".rechts); 

END 

END LinearZuBaum; 

VAR wähl, ch : CHAR; 

p : KnotenPtr; 

BEGIN 

WriteString(”Demonstration eines einfachen Baums”); WriteLn; 

WriteString("Geben Sie 7 Buchstaben in alphabetischer Reihenfolge ein! ”); 
LinearZuBaum(7,Wurzel); 

LOOP 

WriteLn; 

WriteString(”E(infügen, S(uchen, B(aumdruck, L(inear, N(eu, Q(uit ”); 
Read(wahl); WriteLn; 

CASE CAP(wähl) OP 

”E” : WriteString("Zeichen: ”); Read(ch); Einfuegen(Wurzel,ch) | 

”S” : WriteString("Zeichen: ”); Read(ch); 
p := Wurzel; Suchen(p, ch); 

IP p = NIL THEN WriteString(” Nicht im Baum!") 

ELSE WriteString(” gefunden: "); Write(ch) END;j 
”B” : DruckeBaum(Wurzel,0) J 
”L” : BauraZuLinear(Wurzel) | 

”N" : Einrichten() | 

”Q” : EXIT 
ELSE Write(7C) 

END 

END 

END EinfacherBaum. 


Unser kleines Programm hat nur didaktischen Wert. Der Umgang mit ihm soll eine Hilfe zur 
Einarbeitung sein. Wir gehen nun unser eingangs erklärtes Ziel an: die Implementation eines 
Baumes mit Rückzeiger, der beliebige Datentypen verwalten kann. 

Einen Baum mit Rückzeiger stellt man sich so vor (die Wurzel des Baumes ist hier oben, der 
Baum steht also auf dem Kopf): 
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Bild 2.7: Binärer Baum mit Rückzeiger 

Wie man sieht, sind nicht unbedingt alle Äste gleich lang. Als Info speichern wir wieder einen 
Eintrag ab, der auf die eigentlichen Daten zeigt, so wie deren Anzahl Bytes. 

Wir exportieren wiederum einen opaken Typ, hier TREE genannt. Der aufrufende Modul 
muß eine Boolesche »kleiner«-Prozedur übergeben, die es dem Baum ermöglicht, festzustel¬ 
len, welcher von zwei Datensätzen der kleinere ist. 

Der Definitionsmodul sieht dann so aus: 

DEFINITION MODULE Baum; 

FROM SYSTEM IMPORT ADDRESS, BYTE; 

TYPE 

TREE; 

KleinerProzedur = PROCEDURE( (*pl*) ADDRESS, (*p2*) ADDRESS) : BOOLEAN; 

(* 

* Für die Festlegung der *<* - Relation zwischen zwei Schlüsseln. 
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* *pl* und *p2* sind Zeiger auf die zu vergleichenden Daten. 

* Ist 'kleiner* vom Typ ’KleinerProzedur’, so muß gelten: 


* 1. kleiner(a~,a~) = FALSE 

* 2. entweder kleiner(a~,b~) oder kleiner(b Ä ,a~) 


(nicht reflexiv) 
(asymmetrisch) 


* 3. kleiner(a~,b~) & kleiner(b~,c~) ==> kleiner(a~,c") (transitiv) 

*) 

PROCEDURE Einrichten(VAR B : TREE; kl : KleinerProzedur); 

(* 

* Richtet einen binären Baum mit Rückzeiger ein, 

* der gemäß * kl* geordnet ist. 

*■) 

PROCEDURE leer(B : TREE): BOOLEAN; 

(* 

* Ist ’TRUE’, wenn der Baum leer ist. 

*) 

PROCEDURE gefunden(B : TREE): BOOLEAN; 

(* 

* Diese Prozedur ist nach Aufruf von 'Erster», 'Voriger*, ’Naechster’ 

* und »Suche* anzuwenden. Sie liefert »TRUE*, wenn nach diesen Proze- 

* duren im Baum etwas gefunden wird. 

*) 

PROCEDURE Erster(B : TREE); 

(* 

* Sucht nach dem kleinsten Element im Baum. 

*) 

PROCEDURE Naechster(B : TREE); 

(* 

* Sucht das nächstgrößte Element im Baum. 

*) 

PROCEDURE Voriger(B : TREE); 

(* 

* Sucht das nächstkleinere Element im Baum. 

*) 

PROCEDURE Suchen(B : TREE; ziel : ARRAY OF BYTE); 

(* 

* Sucht nach einem Element mit dem Schlüssel »ziel* im Baum. 
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PROCEDURE Einfuegen(B : TREE; inhalt: ARRAY OP BYTE); 
(* 

* Fügt das Datum ’inhalt’ in den Baum. 


PROCEDURE Loeschen(B : TREE); 

(* 

* Ein zu löschendes Element sucht man zunächst mit ’Suchen’ 

* Ergibt anschließend ’gefunden’ TRUE, so kann man es mit 

* ’Loeschen’ aus dem Baum entfernen. 


PROCEDURE HoleDaten(B : TREE; VAR inhalt: ARRAY OP BYTE); 

(* 

* Man sucht einen Schlüssel zunächst mit ’Suchen’. Ergibt ’gefunden’ 

* anschließend ’TRUE’, so können die abgespeicherten Daten mit 

* ’HoleDaten’ ausgelesen werden. 

*) 

PROCEDURE GebeDaten(B: TREE; VAR inhalt: ARRAY OP BYTE); 

(* 

* Diese Prozedur sollte nur im Zusammenhang mit ’Lesen’ in 

* ’LinearZuBaum’ genutzt werden (s.u). 

*) 

PROCEDURE BaumZuLinear(B : TREE; Schreiben : PROC); 

(* 

* Überführt eine Baumstruktur in eine lineare Struktur (ARRAY, Pile). 

* Wie das im einzelnen geschieht, wird in ’Schreiben’ festgelegt. 

* Die ’<’ - Relation wird automatisch dabei berücksichtigt. 

* Typische Anwendung: Sortiertes Abspeichern der Bauminhalte auf eine 

* Datei: ’ Schreiben’ ruft ’HoleDaten’ auf und schiebt jedes Datum auf 

* die Datei. 


PROCEDURE LinearZuBaum(Elementzahl 
Lesen 
kleiner 
VAR B 


(* 


CARDINAL; 

PROC; 

KleinerProzedur; 

TREE); 


Überführt eine lineare, gemäß ’kleiner’ sortierte Struktur in einen 
ausgeglichen Baum. 

Wie das im einzelnen geschieht, wird in ’Lesen’ festgelegt. 

’Lesen’ wird sequentiell von ’LinearZuBaum’ aufgerufen und 
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* muß den nächsten Datensatz mit ’GebeDaten’ dem Baum Übergeben. 

* ’Elementzahl’ ist die Anzahl der zu speichernden Daten. 

* Typische Anwendung: Einlesen der mit ’BaumZuLinear’ auf einer Datei 

* abgespeicherten Bauminhalte. 

*) 

END Baum. 


Der Implementationsmodul »Baum« 

Hier ein Rat an den Leser: Wie erwähnt, ist die Implementation eines Baumes mit Rückzeiger, 
der auf Daten beliebigen Typs operiert, nicht ganz einfach. Wenn Sie vor lauter Zeigern nicht 
mehr sehen, wo es lang geht, so überschlagen Sie diesen Textabschnitt beim ersten Lesen. Um 
mit Bäumen umzugehen, ist es nicht wichtig zu wissen, wie sie implementiert sind (Geheimnis¬ 
prinzip). Lesen Sie dazu den nächsten Teilabschnitt und lassen Sie das Demoprogramm 
laufen. 

Hier also nun weiter für die hartgesottenen »Zeigerverbieger». 

Zunächst einige Begriffserklärungen für Bäume: 

Knoten: 

Verbundvariable mit Inhalt und je einem Zeiger auf den nächsten linken und rechten Knoten. 
Im allgemeinen enthält der linke Knoten dabei einen kleineren Inhalt, der rechte einen größe¬ 
ren als der Knoten selbst. Oft sind auch Rückzeiger zum Vorgänger vorhanden. 

Wurzel: 

Oberster Knoten. Der Rückzeiger der Wurzel ist NIL. 

Blatt (Endknoten): 

Ein unterer Knoten, dessen beide Zeiger links und rechts NIL sind. 

Teilbaum: 

Baum, dessen Wurzel ein Knoten eines anderen Baumes ist. 

Ein nicht leerer binärer Baum besteht also immer aus einer Wurzel und wenigstens einem Teil¬ 
baum. Diese recht einfach formulierte Weisheit enthält eine wesentliche Strategie für effiziente 
Prozeduren zur Verwaltung von Bäumen: rekursive Programmierung. 
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Alle Daten eines Baumes zu bearbeiten (oder auszugeben) ist hiermit ganz einfach: 

PROCEDURE bearbeiten(p: KnotenPtr); 

BEGIN 

IF p # NIL THEN 

bearbeiten(p~.links); 

<bearbeiten oder drucken von p~.info> 
bearbeiten(p~.rechst) 

END 

END bearbeiten; 

Mit bearbe i t en ( wurzel ) kann man so zum Beispiel den gesamten Baum ausgeben; die Pro¬ 
zedur ist (fast) so einfach wie eine FOR-Schleife bei einem Feld: 

FOR i : = MIN(bereich) TO MAX (bereich) DO 
<bearbeiten oder drucken von feld[i]>; 

END; 


Hat man diese grundlegenden Verfahren einmal richtig durchschaut, ist das Verständnis für 
die folgenden Prozeduren und Funktionen einfach zu erlangen. 

Doch zunächst einmal zur Datenstruktur: 

Wir exportieren den Datentyp TREEopak. Ein Zeiger diese Typs zeigt auf einen Verbund vom 
Typ TREEHeader; dieser besteht aus der Wurzel, einem Zeiger Aktueller (zeigt auf den ge¬ 
rade zu bearbeitenden Knoten) und einer Prozedur-Variablen kleiner. Nach der dort ste¬ 
henden Prozedur wird der Baum sortiert. 

Mit Aktueller und Wurzel haben wir Zugriff auf die Knoten des Baumes, in denen wir 
wieder einen Zeiger Eintrag finden, der auf die eigentlichen Daten zeigt: 

Im Implementationsmodul gibt es wieder Testprozeduren, die bei der Programmentwicklung 
hilfreich waren: CheckKnoten (Konsistenz-Überprüfung eines Knotens) und CheckTree 
(Überprüfung der korrekten Verzeigerung der gesamten Baumstruktur). 
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nur dem Implementationsmodul, nicht aber dem Anwender bekannt 


Bild 2.8: Abstrakter Datentyp »TREE« 

Im Implementationsmodul folgen einige Hilfsprozeduren: 

• CopyN zum Kopieren zweier Variablen beliebigen Typs (ist bereits bekannt). 

• NeuerKnoten erzeugt einen neuen Knoten. 

• LöscheKnoten löscht den Knoten und gibt den Speicherplatz wieder frei. 

Nun zu den wichtigen exportierten Prozeduren: 

Einfügen zeigt eine rekursive Vorgehensweise: Man sucht die Einfügestelle indem man von 
der Wurzel ausgehend den Baum hinabsteigt. Ist der einzufügende I nhalt kleiner als der gerade 
betrachtete Inhalt, so ist im linken Teilbaum einzufügen, sonst im rechten. 

Neue Knoten werden grundsätzlich als Blätter eingefügt, ihr linker und rechter Teilbaum sind 
also NIL. Das hat den Vorteil, daß man nicht an bestehenden Verkettungen anderer Knoten 
herumbiegen muß. 
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Das Einfügen von Inhalten mit gleichem Schlüssel ist nach unserer Prozedur zulässig! Wenn 
man zum Beispiel einen Verbund von Nachnamen und Vornamen einer Person im Baum ver¬ 
waltet, und die »kleiner-Prozedur« nur die Nachnamen vergleicht, so wird ein neuer »Meier« 
stets rechts vom bisherigen »Meier« eingefügt. Der neue »Meier« ist also »größer« als der alte. 

Das Löschen in einem Baum ist die komplizierteste Prozedur, sie demonstriert das »Zeiger¬ 
verbiegen« in Reinkultur. 

Nehmen wir an, wir haben den Knoten gefunden, den wir löschen wollen (andernfalls brau¬ 
chen wir ja nichts zu löschen). Nennen wir ihn K. 



Bild2.9: »Beium vordem Löschen« 





























248 Verzeigerte Strukturen 


Dann unterscheiden wir zwei Fälle: 

1. K besitzt höchstens einen nicht leeren Teilbaum; also K. links oder K. rechts ist NIL 

2. kein Teilbaum ist leer, also K. links#NIL und K. rechts#NIL 
Zu 1. 

Hier können wir K einfach »ausketten«, indem man den Vorgänger von K mit seinem Teil¬ 
baum verkettet: Nehmen wir an, K. links sei NIL. Dann biegt man den Pointer des Vor¬ 
gängers, der auf K zeigt, um auf K~. rechts. 

Zu 2. 

Weil K zwei nicht leere Teilbäume besitzt, können wir den Vorgänger nicht einfach auf 
einen der Teilbäume durchketten, da der andere sonst »in der Luft« hinge. Wenn wir K aller¬ 
dings einfach durch seinen nächst kleineren ersetzten (den wir J nennen), stimmt die Reihen- 



Bild 2.10: Baum nach dem Löschen des Knotens »7« 
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folge im Baum immer noch. J ist der größte im linken Teilbaum von K und J. links ist NIL 
(sonst wäre dieser ja größer als J); wir können ihn also einfach wie bei 1. ausketten, und für K 
einketten. 

Da wir das »Überketten« eines Knotens (also das Verbinden seines Vorgängers mit einem 
seiner Nachfolger) öfter brauchen, erledigt das die Prozedur linken (»verbinden«), 
linke (a, b, c) kettet also b aus der Kette a->b->c aus, indem es a->c verbindet. 

Die Implementation der Prozedur HoleDaten, Erster und Letzter ist selbsterklärend. 
Etwas kniffliger ist Naechster, das den Zeiger Aktueller auf den nächst größeren Knoten 
setzt. Hier gibt es drei Fälle zu unterscheiden: 

• Wenn Aktueller=NIL ist, gibt es keinen größeren Knoten. 

• Wenn Aktueller. rechts=NlL ist, geht man solange mittels des Rückzeigers im Baum 
zurück, bis der Rückzeiger nach rechts führt. Landet man vorher bei der Wurzel, gibt es 
keinen größeren mehr. 

• Ansonsten ist Aktueller, rechts ungleich NIL und es gibt einen rechten Teilbaum. 
Von dem nimmt man das kleinste Element: man geht also solange nach links, bis es dort 
keinen »linkeren« (kleineren) mehr gibt. 

Die Prozedur Voriger läuft analog. 

IMPLEMENTATION MODULE Baum; 

PROM SYSTEM IMPORT ADR, ADDRESS, BYTE, TSIZE; 

PROM Storage IMPORT ALLOCATE, DEALLOCATE, Available; 


CONST 


Magic = 12345; 


* nur zum Check *) 


TYPE 


TREE 

KnotenPtr 

TreeHeader 


POINTER TO TreeHeader; 
POINTER TO Knoten; 
RECORD 


Wurzel, Aktueller : KnotenPtr; 


kleiner 

END; 


: Kleinerprozedur; 


Knoten 


RECORD 


ByteZahl 

Eintrag 


: CARDINAL; 
: ADDRESS; 


links, rechts, rueck : KnotenPtr; 


END; 
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(*-Die folgende Prozeduren dienen nur zu Testzwecken-*) 

PROCEDURE checkKnoten(b: TREE; p: KnotenPtr); 

BEGIN (* Test auf korrekte Verzeigerung *) 

WITH p" DO 

IE rueck = NIL THEN 

IP p # b".Wurzel THEN HALT END 
ELSE 

IF (rueck".links # p) AND (rueck".rechts # p) THEN HALT END 

END; 

IF (links # NIL) AND (links ".rueck # p) THEN HALT END; 

IF (rechts # NIL) AND (rechts".rueck # p) THEN HALT END 
END 

END checkKnoten; 

PROCEDURE checkTree(B: TREE); (* Test auf korrekte Verzeigerung *) 

PROCEDURE ct(p, vor: KnotenPtr); 

BEGIN 

IF p <> NIL THEN 

IF p".rueck <> vor THEN HALT END; 
ct(p".links, p); 
ct(p".rechts, p) END 
END ct; 

BEGIN (* checkTree *) 
ct(B".Wurzel, NIL) 

END checkTree; 

(* - Ende Testprozeduren, Beginn des eigentlichen Impl. Moduls - *) 

(* -Hilfsprozeduren- *) 

PROCEDURE CopyN(von, nach: ADDRESS; groesse: CARDINAL); 

VAR 

i: CARDINAL; 

pNach, pVon: POINTER TO BYTE; 

BEGIN 

pVon := von; 
pNach := nach; 

FOR i := 1 TO groesse DO 
pNach" := pVon"; 

INC(pNach); INC(pVon) 

END 

END CopyN; 

PROCEDURE NeuerKnoten(VAR p: KnotenPtr; groesse: CARDINAL); 

BEGIN 
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ALLOCATE(p, TSIZE(Knoten)); 

WITH p" DO 

rueck : = NIL; links := NIL; rechts := NIL; 

ALLOCATE(Eintrag, LONG(groesse)) 

END 

END NeuerKnoten; 

PROCEDURE LoescheKnoten(VAR p: KnotenPtr); 

BEGIN 

DEALLOCATE(p ~.Eintrag, p~.ByteZahl); 

DEALLOCATE(p, TSIZE(Knoten)); 
p : = NIL 

END LoescheKnoten; 

(* -- Ende Hifsprozeduren, Beginn der Impl. der exportierten Prozeduren - *) 

PROCEDURE Einrichten(VAR B: TREE; kl: KleinerProzedur); 

BEGIN 

ALLOCATE(B, TSIZE(TreeHeader)); 

WITH B~ DO 

Wurzel := NIL; Aktueller := NIL; kleiner := kl 
END 

END Einrichten; 

PROCEDURE leer(B: TREE) : BOOLEAN; 

BEGIN 

RETURN B".Wurzel = NIL 
END leer; 

PROCEDURE gefunden(B: TREE): BOOLEAN; 

BEGIN 

RETURN B~.Aktueller # NIL 
END gefunden; 

PROCEDURE Einfuegen(B : TREE; inhalt : ARRAY OP BYTE); 

PROCEDURE Einfuegenl(last: KnotenPtr; VAR p: KnotenPtr);(* lok. Hilfspr *) 
BEGIN 

IP p = NIL THEN 

NeuerKnoten(p, HIGH(inhalt)+1); 

WITH p~ DO 

rueck := last; links := NIL; rechts := NIL; 

ByteZahl := HIGH(inhalt)+1; 

CopyN(ADR(inhalt), Eintrag, HIGH(inhalt)+1) 
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END; 

checkKnoten(B, p); 

B".Aktueller := p 
ELSE 

checkKnoten(B, p); 

IE B" . kleiner(ADR(inhalt), p".Eintrag) THEN 
Einfuegenl(p, p".links) 

ELSE 

Einfuegenl(p, p". rechts) 

END 

END 

END Einfuegenl; (* Ende lok. Hilfsproz.*) 

BEGIN (* Einfuegen *) 

Einfuegenl (NIL, B".Wurzel) 

END Einfuegen; 

PROCEDURE Loeschen(B: TREE); 

VAR p: KnotenPtr; 
a: ADRESS; 
c: CARDINAL; 

PROCEDURE linken(vor,alt,auf: KnotenPtr); 

BEGIN 

checkKnoten(B,alt); 

IE vor = NIL THEN B".Wurzel := auf 
ELSIF vor".rechts = alt THEN vor".rechts 
ELSIF vor".links = alt THEN vor".links 
ELSE HALT END; 

IE auf # NIL THEN checkKnoten(B, auf); auf 
END linken; 

BEGIN (* Loeschen *) 

WITH B" DO 

IE Aktueller = NIL THEN HALT END; 

WITH Aktueller" DO 
IF rechts = NIL THEN 

linken(rueck, Aktueller, links) 

ELSIF links = NIL THEN 

linken(rueck, Aktueller, rechts) 

ELSE (*’Aktueller’ mit seinem nächst kleineren vertauschen *) 

p :s links; 

WHILE p".rechts # NIL DO p := p".rechts END; 

linken(p".rueck, p, p".links); (*Blatt ’p’ aus alter Pos ausketten *) 


(* lokale Hilfsproz. *) 


: = auf 
: = auf 

".rueck := vor END 

(* Ende lokale Hilsproz. *) 
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a := Eintrag; := p~. Eintrag := a; 

c := ByteZahl; Bytezahl := p~. ByteZahl p''. Bytezahl := c; 

Aktueller := p; (* ’p’ ist jetzt ungültig und zu löschen *) 

END 
END; 

LoescheKnoten(Aktueller); 

END 

END Loeschen; 

PROCEDURE HoleDaten(B: TREE; VAR inhalt: ARRAY OP 
BEGIN 

IP B".Aktueller = NIL THEN HALT END; (* 

WITH B~.Aktueller" DO (* 

IP ByteZahl # HIGH(inhalt) + 1 THEN HALT END; 

CopyN(Eintrag, ADR(inhalt), ByteZahl) 

END 

END HoleDaten; 

PROCEDURE GebeDaten(B: TREE; VAR inhalt: ARRAY OP BYTE); 

BEGIN 

IP B~.Aktueller = NIL THEN HALT END; 

WITH B~.Aktueller" DO 

IP Eintrag <> NIL THEN HALT END; (* Test: ’GebeDaten’ darf nur im... *) 
IP ByteZahl <> Magic THEN HALT END; (* ...Zusammenhang mit LinearZuBaum *) 
ByteZahl := HIGH(inhalt)+1; (* ...aufgerufen werden *) 

ALLOCATE(Eintrag, ByteZahl); 

CopyN(ADR(inhalt), Eintrag, ByteZahl) 

END 

END GebeDaten; 

PROCEDURE Erster(B: TREE); 

BEGIN 

WITH B~ DO 

Aktueller := Wurzel; 

IP Aktueller = NIL THEN RETURN END; 

WHILE Aktueller'', links # NIL DO 
Aktueller := Aktueller".links END 

END 

END Erster; 

PROCEDURE Naechster(B: TREE); 

VAR letzter: KnotenPtr; 

BEGIN 


BYTE); 

Programmierfehler, es . . . *) 
... ist nichts zu Holen. *) 


WITH B" DO 
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IF Aktueller = NIL THEN RETURN END; 

IF Aktueller“.rechts = NIL THEN 
REPEAT 

letzter := Aktueller; 

Aktueller := Aktueller“. rueck 
UNTIL (Aktueller = NIL) OR (Aktueller“. links = letzter); 

ELSE 

Aktueller := Aktueller“.rechts; 

WHILE Aktueller“.links # NIL DO Aktueller := Aktueller“.links END 
END 
END 

END Naechster; 

PROCEDURE Voriger(B: TREE); 

VAR letzter: KnotenPtr; 

BEGIN 

WITH B“ DO 

IF Aktueller = NIL THEN RETURN END; 

IF Aktueller“.links = NIL THEN 
REPEAT 

letzter := Aktueller; 

Aktueller : = Aktueller“.rueck 
UNTIL (Aktueller = NIL) OR (Aktueller“. rechts = letzter); 

ELSE 

Aktueller := Aktueller“.links; 

WHILE Aktueller“.rechts # NIL DO Aktueller := Aktueller“.rechts END 
END 
END 

END Voriger; 

PROCEDURE Suchen(B: TREE; ziel: ARRAY OF BYTE); 

VAR p: KnotenPtr; 

BEGIN 

B“.Aktueller := NIL; 
p := B“.Wurzel; 

WHILE p # NIL DO 
B“.Aktueller := p; 

IF B“. kleiner(p“. Eintrag, ADR(ziel)) 

THEN p := p“.rechts 
ELSE p := p“.links 
END 
END; 

IF (B“. Aktueller tt NIL) AND B“. kleiner (B“ . Aktueller“. Eintrag, ADR( ziel)) THEN 
Naechster(B) 



Die Datenstruktur »Baum« 


255 


END 

END Suchen; 

PROCEDURE BaumZuLinear(B : TREE; Schreiben : PROC); 

PROCEDURE BzL(kp: KnotenPtr); (* lokale Hilfsprozedur *) 

BEGIN 

IE kp # NIL THEN 
BzL(kp". links); 

B".Aktueller := kp; 

Schreiben; (* ruft zum Schreiben eines Datums ’HoleDaten’ auf *) 

BzL(kp".rechts) 

END 

END BzL; (* Ende lok. Hilfsproz. *) 

BEGIN (* BaumZulinear *) 

BzL(B".Wurzel); 

B".Aktueller := NIL; 

END BaumZuLinear; 

PROCEDURE LinearZuBaum( 

Elementzahl: CARDINAL; 

Lesen : PROC; 

kleiner : KleinerProzedur; 

VAR B : TREE); 

VAR datenPtr : ADDRESS; 

PROCEDURE LzB(zahl: CARDINAL; vor: KnotenPtr): KnotenPtr; (* lok.Hilfp *) 
VAR neu: KnotenPtr; 

BEGIN 

IE zahl = 0 THEN neu := NIL 
ELSE 

ALLOCATE(neu, TSIZE(Knoten)); 
neu".rueck := vor; 

neu".links := LzB(zahl DIV 2, neu); 

neu".Eintrag := NIL; (* Zur Sicherheit: wird von ’GebeDaten *) 

neu".ByteZahl := Magic; (* ...abgeprüft *) 

B".Aktueller := neu; 

Lesen; (* ruft zum Lesen eines Datums ’Gebedaten’ auf *) 

neu".rechts := LzB(zahl - 1 - zahl DIV 2, neu) 

END; 

RETURN neu; 

END LzB; 


(* Ende lokale Hilfsproz. *) 
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BEGIN (* LinearZuBaum *) 
Einrichten(B, kleiner); 

B*.Wurzel := LzB(ElementZahl, NIL); 
B~.Aktueller := NIL; 
checkTree(B) 

END LinearZuBaum; 

END Baum. 


Das folgende Programm demonstriert das Einfügen, Löschen und Suchen sowie das »Blät¬ 
tern« mit den Prozeduren Voriger und Naechster. 

MODULE BaumDemo; 

FROM SYSTEM IMPORT ADDRESS, ADR; 

FROM InOut IMPORT WritePg, WriteLn, Write, WriteString, WriteLHex, 

Read, ReadString, ReadCard; 

FROM Baum IMPORT TREE, KleinerProzedur, Einrichten, Einfuegen, 

Loeschen, leer, Suchen, gefunden, 

Erster, Naechster, Voriger, HoleDaten, GebeDaten, 

LinearZuBaum, BaumZuLinear; 

IMPORT Strings; 

TYPE 

StrlO = ARRAY[0..9] OF CHAR; 

Person = RECORD 

Name, Vorname : StrlO 
END; 

VAR B : TREE; 

PROCEDURE kleiner(al,a2 : ADDRESS) : BOOLEAN; 

VAR pl,p2: POINTER TO Person; 

BEGIN 

pl := al; p2 := a2; 

RETURN Strings.Compare(pl".Name, p2~ . Name) » Strings.less 
END kleiner; 

PROCEDURE Taste; 

VAR ch : CHAR; 

BEGIN 

WriteLn; WriteString(”<Bitte Taste drücken>”); Read(ch) 

END Taste; 
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PROCEDURE Schreibe(VAR p : Person); 

VAR c: CHAR; i: CARDINAL; 

BEGIN 

WriteLn; 

WriteLn; WriteString(”Name. . . : ”); WriteString(p. Name); 

WriteLn; WriteString(”Vorname: ”); WriteString(p. Vorname); 

WriteLn 
END Schreibe; 

PROCEDURE ListeDrucken(B : TREE); 

VAR 

daten : Person; 

BEGIN 

WritePg; (* Bildschirm loeschen *) 

Erster(B); (* Sucht den kleinsten Datensatz *) 

WHILE gefanden(B) DO 
HoleDaten(B, daten); 

WriteLn; WriteString(daten.Name); 

WriteString(”, ”); WriteString(daten. Vorname); 

Naechster(B) 

END; 

Taste 

END ListeDrucken; 

PROCEDURE Anzahl : CARDINAL; (* Hilfsproz. für LinearZuBaum *) 

VAR anz: CARDINAL; 

BEGIN 

WriteLn; WriteString(”Anzahl: ”); ReadCard(anz); RETURN anz 
END Anzahl; 

PROCEDURE Schreiben; (* als Ausgabedatei wird der Bildschirm benutzt *) 

VAR datum : Person; 

BEGIN 

HoleDaten(B,datum); 

WriteLn; WriteString(”Name: ”); WriteString(datum.Name); 

WriteString(”, Vorname: ”); WriteString(datum.Vorname); 

END Schreiben; 

PROCEDURE Lesen; (* Als Eingabedatei wird die Tastatur benutzt *) 

VAR datum: Person; 

BEGIN 

WriteLn; WriteString(”Name : ”); ReadString(datum. Name); 

WriteString(”Vorname : ”); ReadString(datum.Vorname); 

GebeDaten(B,datum) 
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END Lesen; 


VAR 


wähl, taste 
i 

data 


CHAR; 

CARDINAL; 

Person; 


BEGIN 

Einrichten(B, kleiner); 
REPEAT 


WritePg; 


(* Bildschirm loeschen *) 


IF gefunden(B) THEN 
HoleDaten(B, data); 

Schreibe(data) 

ELSE 

WriteLn; WriteString(» *** Kein Datensatz gewaehlt ***») 

END; 

WriteLn; 

WriteLn; WriteString(”E(infügen, S(uchen, D(rucken”); WriteLn; 
WriteString(»A(uf Datei(=Bildschirm), H(olen von Datei(=Tastatur)”); 

IF gefunden(B) THEN 

WriteLn; WriteString(”V(origer, N(ächster, L(oeschen”) 

END; 

WriteLn; WriteString(»<ESC> = Ende”); 

WriteLn; Read(wahl); WriteLn; 

CASE CAP(wähl) OF 
”N” : Naechster(B) | 

”V” : Voriger(B) | 

”E” : WriteLn; WriteString(»Nachname: ”); ReadString(data.Name); 

WriteLn; WriteString(»Vorname: »); ReadString(data. Vorname); 
Einfuegen(B, data) | 

»L» : IF gefunden(B) THEN Loeschen(B) END | 

»S» : WriteLn; WriteString(»Welchen Namen Suchen: »); 

ReadString(data.Name); 

Suchen(B, data) | 

»D» : ListeDrucken(B) | 

»A» : BaumZuLinear(B,Schreiben); Taste | 

”H” : WriteLn; WriteString(»Namen in alphabet. Reihenfolge eingeben!!!”); 
LinearZuBaum(Anzahl(),Lesen, kleiner, B) 

END 

UNTIL wähl = 33C 
END BaumDemo. 





Software-Engineering bei verzeigerten Strukturen 


259 


Sie werden an diesem Beispielprogramm bemerkt haben, daß der Baum nicht immer »ausge¬ 
glichen« ist, das heißt, daß die Tiefe des linken und rechten Teilbaumes eines Knoten differiert. 
Im extremen Fall kann ein Baum so zu einer »linearen Liste« entarten, zum Beispiel wenn 
nacheinander in der Größe aufsteigende Elemente eingefügt werden. Hier wäre dann der 
linke Teilbaum der Wurzel leer. 

In einem solchen Fall verlängern sich selbstverständlich die Zugriffszeiten beim Suchen. Die 
ideale binäre Struktur ist ja eine Vorraussetzung für ein Suchen mit wenigen Zugriffen (und 
Vergleichen). Hier verschafft folgendes Vorgehen Abhilfe: Man führt einen »Baumausgleich« 
durch. Das geschieht automatisch, wenn man den Baum mit BaumZuLinear auf Diskette 
schreibt und ihn wieder mit LinearZuBaum einliest. Das Ergebnis ist ein ausgeglichener 
Baum. 

Eine andere Methode ist es, direkt beim Einfügen für einen ausgeglichenen Baum zu sorgen. 
Diese Idee wurde zum erstenmal von den russischen Informatikern Adelson-Velskii und 
Landis implementiert. Man spricht von A VL-Bäumen. Hier ist das Maß für die Nichtsymmet¬ 
rie die Höhendifferenz der beiden Unterbäume. In einem ausgeglichenen Baum kann diese 
Differenz nur 0,1 oder -1 betragen. Sollte sich hieran beim Einfügen oder Löschen etwas än¬ 
dern, so wird nach dem »Mobile-Prinzip« rekonfiguriert. Bildlich gesprochen: Hängt das 
Mobile schief (Höhendifferenz betragsmäßig > 1), geht man einen Knoten nach links bzw. 
rechts und hängt es daran wieder auf. Die Implementation eines AVL-Baumes mit Rückzei¬ 
gern würden den Rahmen diese Buches sprengen. Wir verweisen auf die weiterführende Litera¬ 
tur [W6]. Nicht verschwiegen werden soll auch der Geschwindigkeitsverlust beim Einfügen 
und Löschen, der mit dem dauernden Ausgleichen verbunden ist. Eine realistische Anwen¬ 
dung unseres Baummoduls zeigt der nächste Abschnitt über Dateiverwaltung. 

Programmieren lernt man nur durch programmieren! Deshalb zum Schluß noch eine Anre¬ 
gung, wenn Sie selbst mit der Implementation von verketteten Datenstrukturen Erfahrungen 
sammeln wollen: Schreiben Sie einen externen Modul für doppelt verkettete lineare Listen 
(vgl. Abb. »Zeigerstrukturen« aus Abschnitt 1.6.6). Sie können natürlich die gleichen Proze¬ 
durnamen mit den gleichen Funktionen wie im Baummodul implementieren. Es ist nur viel 
einfacher, da sie es mit einer linearen Struktur zu tun haben und Vorgänger bzw. Nachfolger 
immer das nächst kleinere oder größere Element beinhalten. 


2.2.4 Software-Engineering bei verzeigerten Strukturen 

Wer viel arbeitet, macht auch viele Fehler! Dieser Spruch gilt insbesondere für die Program¬ 
mierarbeit mit verzeigerten Strukturen. Wie man an den vorangegangenen Beispielen erken¬ 
nen konnte, haben wir beim Schreiben von Implementationsmodulen stets einige Testproze¬ 
duren mitaufgeführt, die zu dem Zeitpunkt der Programmerstellung die Korrektheit der Ver- 
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zeigerung nach jeder Operation prüften. Aus didaktischen Gründen haben wir diese Überprü¬ 
fungsroutinen nicht gelöscht, sie mögen als Anschauungsmaterial gelten. 

Ein wesentlicher Zweck der Testprozeduren war die Terminierung von Programmen; hierzu 
wurde des öfteren die Prozedur HALT aufgerufen, wenn etwas nicht stimmte. Mit einem 
Debugger läßt sich so eine fehlerhafte Verzeigerung zurückverfolgen. Zur genaueren Über¬ 
prüfung des momentanen Heap-Inhaltes dient auch der Modul TeStorage, der in diesem 
Abschnitt vorgestellt werden soll. Er stellt die Prozedur Speicherliste zur Verfügung, die 
einen »Dump« auf den Bildschirm erledigt. Dabei werden die Speicherinhalte des Heaps mit 
ihrer Bytezahl ausgegeben, numeriert in der Reihenfolge wie sie angefordert wurden. Außer¬ 
dem enthält er noch die Prozeduren ALL0CATE und DEALL0CATE, die hier mit gleichem 
Namen wie in Storage Vorkommen, jedoch leistungsfähiger sind, da die Ausgabe der Spei¬ 
cherliste mit vorbereitet wird. Der Knüller dieser Namensgebung liegt darin, daß nach der 
Testphase des zu entwickelnden Programms in der Importliste die Buchstaben »Te« bei »Te¬ 
Storage« gelöscht werden können, und alles läuft wieder unter Storage ab. Selbstverständ lieh 
sind zuvor die Aufrufe von Speicherliste aus dem fehlerfreien Programm zu entfernen. 

DEFINITION MODULE TeStorage; 

(* 

* Dieser Modul ist in der Entwicklungsphase bei Modulen statt 

* ’Storage’ zu nutzen. Er ermöglicht nach jeder Zeigeroperation 

* die Ausgabe einer Liste der Speicherinhalte auf dem Heap. 

* Ist ein lauffähiges Programm erstellt, so ersetzt man in der 

* IMPORT-Liste einfach ’TeStorage’ durch ’Storage’! 

*) 

PROM SYSTEM IMPORT ADDRESS; 

TYPE 

SizeType = LONGCARD; 

PROCEDURE ALL0CATE(VAR ptr: ADDRESS; groesse: SizeType); 

PROCEDURE DEALLOCATE(VAR ptr: ADDRESS; groesse: SizeType); 

PROCEDURE SpeicherListe; 

END TeStorage. 


IMPLEMENTATION MODULE TeStorage; 

PROM SYSTEM IMPORT TSIZE,ADDRESS; 

PROM InOut IMPORT Write, WriteLn, WriteString, WriteCard; 
IMPORT Storage; 
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CONST 

magConl = 12345; 
magCon2 = 31415; 


TYPE 


nodePtr = POINTER TO node; 

node = RECORD 

magicl : CARDINAL; 

link : nodePtr; 

count : CARDINAL; 

size : SizeType; 

data : ADDRESS; 

raagic2 : CARDINAL 

END; 


VAR 


MasterCount 

StoreList 


CARDINAL; 

nodePtr; 


PROCEDURE Check(p: nodePtr); 

BEGIN 

IE p~.magicl <> magConl THEN HALT END; 

IE p~.magic2 <> magCon2 THEN HALT END 
END Check; 

PROCEDURE MakeCheck(p: nodePtr); 

BEGIN 

p".magicl := magConl; 
p~.magic2 := magCon2; 

END MakeCheck; 

PROCEDURE ALLOCATE(VAR ptr : ADDRESS; groesse : SizeType); 

VAR 

n : nodePtr; 

BEGIN 

INC(MasterCount); 

WriteString(” <ALLOC(”); WriteCard(MasterCount, 1); Write(”,”); 
WriteCard(groesse,1); WriteString(”)> ”); 

Storage.ALLOCATE(n, TSIZE(node)); 

IE n = NIL THEN HALT END; 

Storage. ALLOCATE(ptr, groesse); 

IE ptr = NIL THEN HALT END; (* <!> kein freier Speicher *) 

n~.link := StoreList; 
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n".count := MasterCount; 
n~.size := groesse; 
n~.data := ptr; 

MakeCheck(n); 

StoreList := n; 

END ALLOCATE; 

PROCEDURE DEALLOCATE(VAR ptr : ADDRESS; groesse : SizeType); 

VAR 

vor, n : nodePtr; 

BEGIN 

vor := NIL; 
n := StoreList; 

LOOP 

IE n = NIL THEN HALT END; (* <!> nicht alloziert *) 

Check(n); 

IP n~.data = ptr THEN EXIT END; 
vor := n; 
n : = n".link 
END; 

WriteString(” <DEALL(”); WriteCard(n~.count,1);Write(; 
WriteCard(n~.size,1); WriteString(”)> ”); 

IP n~.size <> groesse THEN HALT END; (* <!> falsche Groesse *) 

IP vor = NIL THEN 

StoreList := n~.link 

ELSE 

vor".link := n~.link 

END; 

Storage.DEALLOCATE(n~.data, n~.size); 

Storage.DEALLOCATE(n, TSIZE(node)) 

END DEALLOCATE; 

PROCEDURE SpeicherListe; 

VAR p: nodePtr; 

BEGIN 

WriteLn; WriteString(” = = = Noch im Heap: 
p :ä StoreList; 

WHILE p <> NIL DO 
Check(p); 

WriteLn; 

WriteString(”); 

WriteCard(p".count,6); WriteCard(p~. size, 6); 
p : = p".link 
END 
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END SpeicherListe; 

BEGIN (* Modul-Initialisierung TeStorage *) 

WriteString(”<TeStorage wird installiert...”); 

MasterCount : = 0; 

StoreList := NIL; 

WriteString(”Ende TeStorage>”); 

END TeStorage. 


Bei der Entwicklung der komplexen verzeigerten Struktur der Module in Kapitel 5 wurde er¬ 
folgreich von TeStorage Gebrauch gemacht. 


2.3 Die Behandlung von Dateien 

Bis jetzt haben wir unsere Daten im Speicher gehalten. V ariablen wurden vom Programm vor¬ 
belegt oder über die Tastatur eingegeben. Für professionelle Anwendungszwecke benötigen 
wir Werkzeuge zum Speichern und Abholen von Daten aus Dateien, die sich auf externen 
Massenspeichern (Diskette, Festplatte, demnächst auch optische Platte) befinden. Im weite¬ 
ren Sinne zählt man zu diesen Dateien auch periphere Ein- und Ausgabemedien wie Tastatur, 
Drucker (ein echtes »write-only«-Medium) oder Modem. 

Daher ist in diesem Zusammenhang auch der Modul inOut zu nennen, mit dem man die 
Ein-/Ausgabe umleiten kann. Hier gibt es die Prozedur RedirectOutput, mit der man den 
Drucker als Ausgabemedium anwählen kann. InOut dient also zu Ein-Ausgabe von Text 
und Zahlen auf Standarddateien. 

In Modula gibt es keine Datenstruktur für Dateien, die zum Sprachumfang selbst gehört. Die 
Dateiverarbeitungs-Werkzeuge sind in externe Module ausgelagert. 

Bereits der Schöpfer der Sprache N. Wirth schlägt hier die Standardmodule Streams und 
Eiles vor. Streams ist für das byte-weise sequentielle Lesen und Schreiben bei Dateien zu¬ 
ständig, man spricht von einem Strom von Bytes (Datenabstraktion). Der hierauf aufbauende 
Modul Files ermöglicht größere Dateioperationen, wie man sie von anderen Sprachen wie 
Pascal her kennt. Es werden hier Lese- und Schreiboperationen für Standard-Datentypen be¬ 
reitgestellt. Leider differieren die Module zur Dateiverarbeitung bei jedem Modula-System 
für den Atari. Hier eine kurze Übersicht: 

TDI-Modula hält sich im großen und ganzen an das von Wirth vorgeschlagene Konzept. Es 
gibt die Module mit dem Namen Streams und Text 10 . Ähnlich bei Hänisch-Modula, dessen 
Bibliothek sich stark an die Definition von Martin Odersky anlehnt. Es werden die Module 
Files und TextIO bereitgestellt. 
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Bei SPC-Modula findet man die Module By t eSt reams für sequentielle byte- und word-weise 
I/O-Operationen (I/O steht für input/output , »Ein-/Ausgabe«) und Textstreams. Letzterer 
erlaubt die Ein- und Ausgabe auf ASCIl-Files ähnlich den Prozeduren aus inOut. Weiterhin 
gibt es FileSystem für Dateien mit Direktzugriff (random file access), wobei gleichzeitiges 
Lesen und Schreiben auf jede Stelle des Files möglich ist. Textfiles unterstützt Textdateien 
mit Direktzugriff. Das Einfügen ( insert ) von Zeichen in das File ist möglich. 

Das MSM2-System bietet die Module Streams, Filesund FilelO. Letzterer implementiert 
die Ein-/Ausgabe auf Dateien und ist im großen und ganzen mit InOut kompatibel, was recht 
bequem ist. 

Zum Megamax-Dateisystem gehören: Files zum Öffnen und Schließen von Dateien. 
Binary für byte-weise (nicht textuelle) Ein-/Ausgabe von Daten auf Files. Dieser Modul ent¬ 
spricht am ehesten Streams, jedoch ist Direktzugriff mit der Prozedur Seek möglich. Text 
dient für die Ein-/Ausgabe von Textdateien auf beliebige Daten; NumberlOfür Ein-/Ausgabe 
von Zahlen in Textfiles auf beliebige Dateien. 

Die folgenden Beispielprogramme beziehen sich wieder auf Megamax-Modula. Da sie aus¬ 
führlich erklärt werden, dürfte es keine Schwierigkeit bereiten, sie für ein anderes System um¬ 
zuschreiben. 


2.3.1 Einführende Beispiele 

Das Einfachste, was man mit Diskettendateien machen kann, ist: 

1. die Datei mit einem bestimmten Namen öffnen 

2. sequentiell etwas Abspeichern 

3. die Datei wieder schließen 

Ein zweites Programm kann dann diese Datei wieder öffnen, die Daten in den Kernspeicher 
lesen. Als »Daten« nehmen wir im ersten Beispiel einen Text, im zweiten die Zahlen 1 bis 10. 

MODULE SchreibeTextAufDatei; 

FROM InOut IMPORT Read, ReadString, WriteString, WriteLn; 

FROM Files IMPORT Create, Close, File, Access, ReplaceMode; 

IMPORT Text; 

VAR f : File; 

FileName, s : ARRAY [0-80] OF CHAR; 

taste : CHAR; 

CARDINAL; 


1 
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BEGIN 

WriteString(”Demonstration des Schreibens auf eine Textdatei”); WriteLn; 
WriteString(”Geben Sie den kompletten Pfadnamen für die Datei an: ”); 
ReadString(FileName); 

Create(f,FileName,writeSeqTxt,replaceOld); 

FOR i:=0 TO 3 DO 

WriteString(”Text: ”); ReadString(s); 

Text.WriteString(f, s); 

Text.WriteLn(f) 

END; 

Close(f); 

WriteString(”Ihren Text können Sie mit dem Programm ’LiesText’ lesen.”); 
Read(taste); 

END SchreibeTextAufDatei. 


Die vier Textzeilen, die man mit diesem Programm geschrieben hat, kann man mit dem Editor 
ansehen. Oder auch mit dem folgenden Programm: 

MODULE LiesTextVonDatei; 

FROM InOut IMPORT Read, ReadString, WriteString, WriteLn; 

FROM Files IMPORT Open, Close, File, Access, EOF; 

IMPORT Text; 

VAR f : File; 

FileName, s : ARRAY [0..80] OF CHAR; 

taste : CHAR; 

BEGIN 

WriteString(Demonstration des Lesens von einer Textdatei”); WriteLn; 
WriteString(”Geben Sie den kompletten Pfadnamen für die Datei an: ”); 
ReadString(FileName); 

Open(f,FileName,readSeqTxt); 

WHILE NOT EOF(f) DO 
Text.ReadString(f, s); 

WriteString(s); 

WriteLn 

END; 

Close(f); 

Read(taste); 

END LiesTextVonDatei. 
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Das Programm kann natürlich auch andere Textfiles lesen, zum Beispiel Ihre Modula-Pro- 
grammtexte. 

Mittels der Routinen aus NumberlO können auch Zahlen in die Textdatei geschrieben wer¬ 
den: 

MODULE SchreibeZahlenAufDatei; 

FROM InOut IMPORT Read, ReadString, WriteString, WriteCard, WriteLn; 

FROM Files IMPORT Create, Close, File, Access, ReplaceMode; 

IMPORT NumberlO; 

IMPORT Text; 

VAR f : File; 

FileName : ARRAY [0..80] OF CHAR; 

taste : CHAR; 

i : CARDINAL; 

BEGIN 

WriteString(”Demonstration des Speichern von Zahlen auf eine Datei”); WriteLn; 
WriteString(”Geben Sie den kompletten Pfadnamen für die Datei an: ”); 
ReadString(FileName); 

Create(f,FileName,writeSeqTxt,replaceOld); 

FOR i:=0 TO 10 DO 

WriteCard(i,3); WriteLn; 

NumberlO.WriteCard(f, i, 3); 

Text.WriteLn(f) 

END; 

Close(f); 

WriteString(”Diese Zahlen können Sie mit dem Programm ’LiesZahl’ lesen.”); 

Read(taste); 

END SchreibeZahlenAufDatei. 


Zum Lesen nun: 

MODULE LiesZahlenVonDatei; 

FROM InOut IMPORT Read, ReadString, WriteString, WriteLn, WriteCard; 
FROM Files IMPORT Open, Close, File, Access, EOF; 

IMPORT NumberlO; 


VAR f 


: File; 
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FileName 


ABRAY [0..80] 0F CHAE; 
CARDINAL; 

CHAR; 

BOOLEAN; 


i 


taste 

ok 


BEGIN 

WriteString("Demonstration des Lesens von Zahlen aus einer Datei”); WriteLn; 
WriteString(”Geben Sie den kompletten Pfadnamen für die Datei an: ”); 
ReadString(FileName); 

Open(f,FileName,readSeqTxt); 

WHILE NOT EOF(f) DO 

NumherlO.ReadCard(f,i, ok); 

IF ok THEN WriteCard(i,6) END; 

END; 

Close(f); 

Read(taste); 

END LiesZahlenVonDatei. 

Im nächsten Abschnitt sieht man, wie Verbünde, die verschiedene Datentypen enthalten, ab¬ 
zuspeichern sind. Außerdem wird hier gezeigt, wie schnell auf einen bestimmten Datensatz zu¬ 
gegriffen werden kann, ohne jedesmal die gesamte Datei sequentiell zu durchlaufen. 

2.3.2 Die Verwaltung einer Datei mit einem Baum 

Wir haben im Vorwort versprochen, sowohl für den Anfänger als auch für den Fortgeschritte¬ 
nen interessant zu bleiben. Aus diesem Grund geht es nun im Niveau steil hoch zu einer profes¬ 
sionellen Anwendung. Dieser Abschnitt wird ein relativ komplexes Programm bringen. Um 
nun nicht gleich den Anfänger zu entmutigen, sei gesagt, daß es ab dem nächsten Abschnitt 
wieder mit wesentlich reduziertem Schwierigkeitsgrad weitergeht. Legen Sie also das Buch 
nicht gleich weg, wenn Sie beim ersten Lesen mit diesem Abschnitt nicht zurecht kommen. 
Überschlagen Sie ihn einfach, er wird für den weiteren Verlauf nicht weiter gebraucht! Lesen 
Sie diesen Abschnitt erneut, wenn Sie in den folgenden Kapiteln mehr Programmiererfahrung 
gesammelt haben. 

Der auf Diskette zu speichernde Datentyp lautet (vgl. Abschnitt 2.1): 

TYPE KundenTyp = RECORD 


KundenNr 
Name,Vorname 
Wohnort 


CARDINAL; 

str20; 

str20 


END; 
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Zur Verwaltung braucht man folgendes: 

1. Möglichkeit der Eingabe eines Kunden und anschließendes Abspeichern in der Kunden¬ 
datei 

2. Möglichkeit des Suchen eines Kunden, Schlüssel ist hierbei der Nachname 

3. Möglichkeit des »Vor- und Rückwärtsblätterns« in der Datei 

4. Möglichkeit des Löschens des Kunden 
Zu 1. 

Eingegeben werden die Kunden über eine Eingabemaske für die vier Komponenten des 
Verbundes. Es ist chic, solche Eingabemasken mit der GEM-Oberfläche des Atari anzu¬ 
fertigen; hierzu kommen wir aber erst im 4. Kapitel. Wir bringen hier einen Modul, der et¬ 
was altmodisch Eingaben auf dem Text-Bildschirm gestattet. In Millionen Verwaltungen 
haben Eingabemasken ein ähnliches Design! Die eingegebenen Personen werden in der 
Reihenfolge abgespeichert, wie sie ankommen. In der Kundendatei ist alles wild durchein¬ 
ander. Wir sorgen dafür, das trotzdem alles sortiert aussieht! 

Zu 2. 

Damit wir in der chaotischen Kundendatei schnell etwas finden, brauchen wir eine geord¬ 
nete »stützende« Struktur neben ihr. Wir wählen dazu einen geordneten binären Baum mit 
Rückzeiger, dessen Einträge den Schlüssel KundenName und der Position des entspre¬ 
chenden Datensatzes in der Kundendatei besteht. Hierdurch ist eine schnelle Suchmög¬ 
lichkeit und Zugriff auf einen Kunden gegeben. 

Die hier vorgeschlagene Methode, über einen Baum (auch über eine Listen-oder ARRAY- 
Struktur) auf einen bestimmten Datensatz einer Datei zuzugreifen, heißt ISAM (Index Search 
(oder Sequential) Access Method). 

In der folgenden Reihenfolge werden beispielsweise Kunden eingegeben. Diese bleiben auf der 
Datei ungeordnet: 

Nachname Datensatznummer 


Klein 

Duck 

Zorro 


1 

2 

3 
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Der geordnete Kundenbaum hat dann die Einträge: 
Nachname Datensatznummer 


Duck 2 

Klein 1 

Zorro 3 

Wie man an diesem Beispiel sieht, läßt sich eine Datei mit wahlfreiem Zugriff auch über Stütz¬ 
felder verwalten. Bäume sind aber effizienter beim Einfügen und Löschen. 

Zu 3. 

Das Vor- und Rückblättern ist durch unsere »Baum mit Rückzeiger«-Struktur nun kein 
Problem mehr. 

Zu 4. 

Wenn ein Datensatz gelöscht werden soll, wird man ihn zunächst über den Kundennamen 
suchen und auf dem Bildschirm anzeigen. ln den beiden Bäumen sind die entsprechenden 
Daten ebenfalls zu löschen. In der Kundendatei entstehen durch das Löschen mit der Zeit 
»Löcher«, die wir wieder für neu eingegebene Kunden benutzen können. Dazu muß man 
aber wissen, welche Datensätze in der Datei nicht belegt sind. Also benötigt man noch eine 
Struktur, die die Löcher festhält. Hier bietet sich ein Stapel an. Wir speichern dabei die 
Verweise auf den nächsten Datensatz in den gelöschten Datenfeldern. 

Aus der Beschreibung dürfte klar geworden sein, daß wir eine recht komfortable, aber auch 
aufwendige Dateiverwaltung implementierten. Nach dem Leitsatz »ein fertiges Programm ist 
ein veraltetes Programm«, könnten Sie noch versuchen, einen weiteren Stützbaum für die 
Kundennummern als zweiten Suchschlüssel anzulegen. Die benötigten Strukturen dafür sind 
bereits vorhanden! 

Die obigen Ausführungen mögen als Entschuldigung dafür reichen, warum das Programm 
ziemlich lang geraten ist. 

MODULE DateiverwaltungMitStuetzBaum; 

PROM SYSTEM IMPORT ADDRESS; 

PROM Tastatur IMPORT lies, SLinks, SRechts, PHoch, PTief, 

PI, F2, F3, F4, F5, F6, F7, F8, F9, PIO; 

PROM Eingabe IMPORT Glocke, LiesZeichen, LiesWort, LiesCard; 

PROM InOut IMPORT GotoXY, Write, WriteString, WriteCard, WritePg, FlushKbd, 
ReadString; 

PROM Strings IMPORT String, Compare, Relation; 

IMPORT Files, Binary; 
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IMPORT Baum; 

CONST (* >>>>>>>>>>> Bitte nach Bedarf ändern *) 

FileFuerDaten = ”F: \TEST. DAT”; (* Pfad für Hauptdatei *) 

FileFuerNamen = ”F: \TEST. NAM”; (* Pfad für Stützdatei *) 

CONST RET = 13; ESC = 33C; 

TYPE 

Str20 = ARRAY [0..19] OF CHAR; 

Fileindex = LONGINT; 

KundenTyp = RECORD 

KundenNr : CARDINAL; 

Name, Vorname : Str20; 

Wohnort : Str20; 

END; 

NameTyp = RECORD 

Name : Str20; 

SatzNr : Fileindex 
END; 

VAR Aktu : RECORD 

Kunde: KundenTyp; 

SatzNr: Fileindex; 

END; 

Bank: RECORD 

NamenPath, DatenPath: String; 

NamenFile, DatenFile: Files.File; 

NamenBaum: Baum.TREE 
END; 

wähl : CARDINAL; 

PROCEDURE invers; 

BEGIN Write(ESC); Write(”p”) END invers; 

PROCEDURE normal; 

BEGIN Write(ESC); Write(”q”) END normal; 

PROCEDURE LoeschZeile(zeile : CARDINAL); 

BEGIN GotoXY(0,zeile); Write(ESC); Write(”K”) END LoeschZeile; 


PROCEDURE Meldung(s: ARRAY OF CHAR); 
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BEGIN 

LoeschZeile(17); GotoXY(2,17); WriteString(s); 
END Meldung; 

PROCEDURE Frage(s : ARRAY OF CHAR) : BOOLEAN; 
BEGIN 

Meldung(s); WriteString(” (j/n)? ”); 

RETURN CAP(LiesZeichen(”JjNn”)) = ”J” 

END Frage; 

PROCEDURE NamenKleiner(pl, p2: ADDRESS): BOOLEAN; 
VAR 

pStl, pSt2: POINTER TO NameTyp; 

BEGIN 

pStl := pl; pSt2 : = p2; 

RETURN Compare(pStl Ä .Name,pSt2~ . Name) = less 
END NamenKleiner; 


(,* 


Datei-Verwaltung 


MODULE DateiVerwalter; 

IMPORT Fileindex,KundenTyp, Bank, Baum, NamenKleiner, NameTyp, 

Files, Binary; 

EXPORT LiesKunde, SchrKunde, NeuerKunde, LoescheKunde, KundenAnzahl, 
DatenErzeugen, DatenEinlesen, DatenSichern; 


TYPE 


HeaderTyp = RECORD Highindex,ErsteFreie: Fileindex; Anzahl: CARDINAL END; 
SatzArt = (satzFrei, satzBelegt, satzHeader); 

SatzTyp = RECORD 

CASE Art: SatzArt OF 


satzFrei 

satzBelegt 

satzHeader 

END 

END; 


NaechsteFreie : Fileindex | 
Info : KundenTyp | 
Header : HeaderTyp 


VAR 


Header : HeaderTyp; 
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PROCEDURE WriteSatz(nr: Fileindex; VAR satz: SatzTyp); 

BEGIN 

Binary. Seek(Bank.DatenFile, nr*FileIndex(SIZE(satz)), Binary.fromBegin); 
Binary.WriteBlock(Bank.DatenFile, satz) 

END WriteSatz; 

PROCEDURE ReadSatz(nr: Fileindex; VAR satz: SatzTyp); 

BEGIN 

Binary. Seek(Bank.DatenFile, nr*FileIndex(SIZE(satz)), Binary. fromBegin); 
Binary.ReadBlock(Bank.DatenFile, satz) 

END ReadSatz; 

PROCEDURE NeuerKunde: Fileindex; 

VAR 

satz : SatzTyp; 
frei : Fileindex; 

BEGIN 

INC(Header.Anzahl); 

IF Header.ErsteFreie = OD THEN 
INC(Header. Highindex); 

RETURN Header.Highindex 
ELSE 

frei := Header.ErsteFreie; 

ReadSatz(frei, satz); 

Header.ErsteFreie := satz.NaechsteFreie; 

RETURN frei 
END 

END NeuerKunde; 

PROCEDURE LoescheKunde(nr: Fileindex); 

VAR satz: SatzTyp; 

BEGIN 

satz.Art := satzFrei; 

satz.NaechsteFreie := Header.ErsteFreie; 

Header.ErsteFreie := nr; 

WriteSatz(nr, satz); 

DEC(Header. Anzahl) 

END LoescheKunde; 

PROCEDURE LiesKunde(nr: Fileindex; VAR künde: KundenTyp); 

VAR satz: SatzTyp; 

BEGIN 

ReadSatz(nr, satz); 
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IF satz.Art # satzBelegt THEN HALT END; 
künde := satz.Info 
END LiesKunde; 

PROCEDURE SchrKunde(nr: Pilelndex; VAR künde: KundenTyp); 

VAR satz: SatzTyp; 

BEGIN 

satz.Art := satzBelegt; 
satz.Info : = künde; 

WriteSatz(nr, satz); 

END SchrKunde; 

PROCEDURE KundenAnzahl: CARDINAL; 

BEGIN RETURN Header.Anzahl END KundenAnzahl; 

PROCEDURE LiesNamen; 

VAR name: NaraeTyp; 

BEGIN 

Binary. ReadBlock (Bank.NamenPile, name); 

Baum.GebeDaten (Bank.NamenBaum, name) 

END LiesNamen; 

PROCEDURE SchrNaraen; 

VAR name: NameTyp; 

BEGIN 

Baum.HoleDaten (Bank.NamenBaum, name); 

Binary.WriteBlock (Bank.NamenPile, name) 

END SchrNamen; 

PROCEDURE DatenErzeugen: BOOLEAN; 

BEGIN 

Piles.Create(Bank.DatenFile,Bank.DatenPath, Files. readWrite,Files.noReplace); 
IF Files. State(Bank.DatenFile) < 0 THEN RETURN FALSE END; 

Files.Create(Bank.NamenFile,Bank.NamenPath, Files. readWrite, Files.noReplace); 
IF Files.State(Bank.DatenFile) < 0 THEN RETURN FALSE END; 

Baum.Einriehten(Bank.NamenBaum, NamenKleiner); 

Header.Highindex : = OD; 

Header.ErsteFreie := OD; 

Header.Anzahl := 0; 

RETURN TRUE 
END DatenErzeugen; 


PROCEDURE DatenEinlesen: BOOLEAN; 
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VAR satz: SatzTyp; 

BEGIN 

Files. Open(Bank.Datenfile, Bank.DatenPath, Files.readWrite); 

IF Files.State(Bank.DatenFile) < 0 THEN RETURN FALSE END; 

Files.Open(Bank.NamenFile, Bank.NamenPath, Files.readWrite); 

IF Files. State(Bank.NamenFile) < 0 THEN RETURN FALSE END; 

ReadSatz(OD, satz); (* Datenbank-Header einiesen *) 

IF satz.Art # satzHeader THEN HALT END; 

Header := satz.Header; 

Baum. LinearZuBaum(Header.Anzahl, LiesNamen, NamenKleiner, Bank. NamenBaum); 
RETURN TRUE 
END DatenEinlesen; 

PROCEDURE DatenSichern; 

VAR satz: SatzTyp; 

BEGIN 

satz.Art : = satzHeader; 
satz.Header := Header; 

WriteSatz(OD, satz); (* Datenbank- Header sichern *) 

Binary. Seek(Bank.NamenFile, OD, Binary.fromBegin); 

Baum. BaumZuLinear(Bank.NamenBaum, SchrNamen); (* Baum auf Datei sichern *) 
Files.Close(Bank.DatenFile); 

Files.Close(Bank.NamenFile) 

END DatenSichern; 

END Dateiverwalter; 


(* = = = = = = = = = = = — = = = = = = = = = = = = = = = = = = = — = = = = = = = = = = = = = = = = = = = = = = = = -) 
PROCEDURE LeerKunde; 

BEGIN 

WITH Aktu.Kunde DO 

KundenNr := 9999; Name[0] := OC; Vorname[0] := OC; Wohnort[0] := OC END; 
END LeerKunde; 


PROCEDURE ZeigeKunde; 

BEGIN WITH Aktu.Kunde DO 
LoeschZeile(10); 

LoeschZeile(14); 

GotoXY(2, 10); WriteString(”Kundennr. 
GotoXY(40,10); WriteString("Nachname 
GotoXY(2 ,14); WriteString("Vorname 
GotoXY(40,14); WriteString(”Wohnort 
END END ZeigeKunde; 


”); WriteCard(KundenNr, 4); 
”); WriteString(Name); 

"); WriteString(Vorname); 
”); WriteString(Wohnort) 
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PROCEDURE ZeigeMaske; 

VAR name: NameTyp; 

BEGIN 

IF Baum.gefunden(Bank.NamenBaum) THEN 
Meldung(””); 

ZeigeKunde 

ELSE 

LeerKunde; ZeigeKunde; 

Meldung(”<kein Kunde gefunden>”) 

END; 

GotoXY(2,7); WriteString(”Satz Nr.:”); WriteCard(Aktu.SatzNr, 5); 

WriteString(”, von: ”); WriteCard(KundenAnzahl(), 5 ) 

END ZeigeMaske; 

PROCEDURE LadeAktuellen; (* Holt die Datensatz-Nr. aus der Baum und... *) 

VAR (* ...holt den vollständigen Kunden aus der Datei *) 

name: NameTyp; 

BEGIN 

IF Baum.gefunden(Bank.NamenBaum) THEN 
Baum.HoleDaten(Bank.NamenBaum, name); 

Aktu.SatzNr := name.SatzNr; 

LiesKunde(Aktu.SatzNr, Aktu.Kunde); 

ELSE 

Aktu.SatzNr : = OD; 

END 

END LadeAktuellen; 

PROCEDURE speichern; 

VAR name : NameTyp; 

neue : Fileindex; 

BEGIN 

neue := NeuerKunde(); 

name.Name := Aktu.Kunde.Name; 

name.SatzNr := neue; 

Baum.Einfuegen(Bank.NamenBaum, name); 

SchrKunde(neue, Aktu.Kunde); 

Aktu.SatzNr := neue; 

END speichern; 

PROCEDURE Einfuegen; 

VAR 

nr, EndTaste : CARDINAL; 

BEGIN 

LeerKunde; ZeigeKunde; 
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Meldung("Geben Sie einen Kunden ein (<ESC> = fertig)!"); 
nr : = 0; 

REPEAT 

WITH Aktu.Kunde DO 
CASE nr OE 

0 : LiesCard(14,10,1,9999,KundenNr, EndTaste) | 

1 : LiesWort(52,10,20,Name,EndTaste) | 

2 : LiesWort(14,14,20,Vorname,EndTaste) | 

3 : LiesWort(52,14,20,Wohnort, EndTaste) 

END 

END; 

CASE EndTaste OE 


PHoch 

IF 

nr < 2 

THEN 

Glocke 

ELSE 

DEC(nr,2) 

END | 


PTief 

IF 

nr > 1 

THEN 

Glocke 

ELSE 

INC(nr,2) 

END | 


SRechts 

IF 

ODD(nr) 

THEN 

Glocke 

ELSE 

INC(nr) 

END | 

(* Shift --> *) 

SLinks 

IF ODD(nr) 

THEN 

DEC(nr) 

ELSE Glocke 

END | 

(* Shift <-- *) 

RET 

nr 

:= (nr+1) MOD 4; 






END; 

UNTIL EndTaste = 27; 

IF Frage("Abspeichern”) THEN speichern ELSE LadeAktuellen END; 
END Einfuegen; 

PROCEDURE Loeschen; 

VAR name: NameTyp; 

BEGIN 

IF NOT Baum.gefunden(Bank.NamenBaum) THEN Glocke; RETURN END; 
IF Frage("Wirklich löschen") THEN 

Baum.HoleDaten(Bank.NamenBaum, name); 

IF name.SatzNr # Aktu.SatzNr THEN HALT END; 

Baum.Loeschen(Bank.NamenBaum); 

LoescheKunde(Aktu.SatzNr); 

END; 

END Loeschen; 

PROCEDURE Suchen; 

VAR name: NameTyp; 

BEGIN 

Meldung("Welchen Namen suchen: "); 

ReadString(name. Name); 

Baum.Suchen(Bank.NamenBaum, name); 

LadeAktuellen 
END Suchen; 


PROCEDURE Naechster; 
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BEGIN 

Baum.Naechster(Bank.NamenBaum); LadeAktuellen 
END Naechster; 

PROCEDURE Voriger; 

BEGIN 

Baum. Voriger(Bank.NamenBaum); LadeAktuellen 
END Voriger; 

PROCEDURE Ende; 

BEGIN 

Meldung(”Bitte etwas Geduld, es werden noch Daten abgespeichert!”); 
DatenSichern 
END Ende; 

BEGIN 

Bank.NamenPath := FileEuerNamen; 

Bank.DatenPath := FileFuerDaten; 

IF DatenEinlesen() THEN Meldung(”Alte Daten Werden gelesen...”) 

ELSIF DatenErzeugen() THEN Meldung(”Eine neue Datei wird erzeugt...”) 

ELSE Meldung(”Dateien defekt oder unvollständig!”); lies(wähl); HALT END; 
REPEAT 

ZeigeMaske; 
invers; 

GotoXY( 1,20); 

GotoXY(14,20); 

GotoXY(27,20); 

GotoXY(39,20); 

GotoXY(52,20); 

GotoXY(66,20); 
normal; 

FlushKbd; 
lies(wähl); 

LoeschZeile(20); (* Menü wegmachen *) 

CASE wähl OF 

Fl : Einfuegen | F2 : Loeschen | F3 : Suchen 
F4 : Voriger | F5 : Naechster | F10: Ende 
ELSE Glocke END 
UNTIL wähl = F10; 

END DateiverwaltungMitStuetzBaum. 


(* Menü invers darstellen 
WriteString(” Eingabe Fl ”); 
WriteString(” Löschen F2 ”); 
WriteString(” Suchen F3 ”); 
WriteString(” Voriger F4 ”); 
WriteString(” Nächster F5 ”); 
WriteString(” Ende F10 ”); 
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2.4 Hashen, schneller als Sortieren 

Im großen und ganzen geht es in diesem zweiten Kapitel um das Abspeichern und schnelle 
Wiederfinden von Daten. Hierzu wurden Verfahren mittels Felder, Bäumen und Dateien auf¬ 
gezeigt. Dabei haben wir die Datenmenge stets in irgendeiner raffinierten Weise auf eine sor¬ 
tierte Struktur abgebildet. Möglicherweise stehen Sie mit den Zeigern noch auf Kriegsfuß. 
Das nun vorgestellte Verfahren des »Hashens« läßt sich sowohl auf das Finden von Daten in 
ungeordneten Feldern als auch auf ungeordnete Dateien anwenden, ist bei nicht zu großen 
Datenbeständen sehr schnell und - das ist der Knüller - ganz einfach zu programmieren! 

Damit das Wesentliche klar zum Vorschein kommt, demonstrieren wir das Hash-Verfahren 
an einem Feld, für Dateien funktioniert es analog. 

Wir präzisieren die Problemstellung: 

Gegeben ist ein ungeordnetes Feld vom Typ KundenTyp (vgl. 2.1): 

VAR feld: ARRAY [0..raax] OF KundenTyp; 

Suchschlüssel sei der Nachname vom 

TYPE str20 = ARRAY[0..19] OF CHAR; 

Bevor nun ein neuer Kunde in das noch leere Feld abgespeichert wird, »zerhacken« (engl, hash 
»zerhacken«) wir den Schlüssel etwa mit der folgenden Funktion: 

PROCEDURE Hash(Schluessei: ARRAY OF CHAR): CARDINAL 
VAR hashwert,i: CARDINAL; 

BEGIN 

Hashwert := 0; 
i := 0; 

WHILE (i <= HIGH(Schluessel)) AND (Schluessel[i] # 0) DO 
INC(hashwert, 0RD(Schluessel[i])); 

INC(i); 

END; 

RETURN hashwert MOD (max + 1) 

END Hash; 


Diese Funktion hat nur den Sinn, einem Schlüssel eine beliebige Zahl aus dem Intervall 
[0..max] zuzuordnen, die möglichst für verschiedene Schlüssel verschieden sein soll. Diese 
Zahl nennt sich »Hash-Wert«. 
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Hat nun ein Kundenname den Hashwert h, so wird er an der Position f eld [ h ] abgespeichert. 
Wir speichern einen Datensatz also einfach bei seinem Hashwert! 

h := Hash(künde. Name); 
feld[h] := künde; 

Das ist alles! Und wenn man einen Kunden mit dem Namen »Meier« sucht: 

künde := feld[Hash(”Meier”)]; 

und schon haben wir ihn! Abspeichern und Suchen also mit einem kurzen Zugriff! Leider hat 
die Sache einen kleinen Haken: die »Kollisionen«. Es kann nämlich Vorkommen, das zwei ver¬ 
schiedene Schlüssel den selben Hashwert haben! Beispielsweise haben ”Moduia” und ”Ma- 
dulo” mit obiger Hash-Funktion beide den Hash-Wert 610. Mathematisch gesehen ist Hash 
also nicht injektiv. Das geht auch gar nicht, da es mehr verschiedene Strings als CARDINAL- 
Zahlen gibt. 

Aber man kann schlecht zwei Datensätze in dem selben Feldelement speichern. Eine einfache 
Möglichkeit ist es, den nächsten freien Platz zu nehmen, also den Index h so lange zu erhö¬ 
hen, bis ein freier Platz gefunden ist. Diese Methode nennt sich »lineares Sondieren«. Sie führt 
aber zu Ballungen in der Feldbesetzung. Eine bessere Verteilung der Daten über das ganze 
Feld liefert das »quadratische Sondieren«. Dabei erhöht man hnicht um eins, sondern setzt es 
um eine Quadratzahl weiter: bei jeder Kollision macht h also größere Schritte. Läuft man 
dabei oben heraus (h>max), macht man wieder unten weiter. 

Da die Quadratzahlen 1,4,9,16,25... im Abstand von 3,5,7,9 voneinander liegen, braucht man 
natürlich nicht dauernd i*i zu berechnen (Multiplikationen benötigen relativ viel Zeit): 

d : = 1; (* Abstand zur nächsten Quadratzahl initialisieren *) 

h := Hash(Schluessel); 

WHILE <Feld bei egt> DO 
INC(h,d); INC(d,2); 

IF h >= max+1 THEN h := h-(max+l) 

END; 

Beim Suchen nach einem Element geht man analog vor: Ist das Element Hash( Schiuessel) 
von einem anderem Datensatz belegt, muß man durch quadratisches Sondieren weitersuchen. 

Die Theorie zeigt, daß man schnell freie Plätze findet, wenn max+l eine Primzahl ist. Damit 
nicht zu lange im Feld nach freien Plätzen »rotiert« wird, wählt man das Feld auch gerne ca. 
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10% größer, als man es eigentlich benötigt. Im Programm wählen wir max=lOO, da 101 eine 
Primzahl ist. 

MODULE HashDemo; 

FROM RandomGen IMPORT Randomize, RandomCard; 

PROM InOut IMPORT WriteString, WriteLn, ReadString, WriteCard; 

IMPORT Strings; 

CONST prim = 101; (* Primzahl, Anzahl der Feldelemente *) 

max = prim-1; 

TYPE 

Str4 = ARRAY [0..3] OF CHAR; 

Verbund = RECORD 

Schluessel : Str4; 

(* Info : InfoTyp *) (* hier beliebige Daten *) 

END; 

VAR 

feld : ARRAY [0..max] OF Verbund; 

Element : Verbund; 

PROCEDURE DummyFeld; 

VAR i : CARDINAL; 

BEGIN 

FOR i:=0 TO max DO feld[i].Schluessel := ”” END; (* Kennung für unbelegt *) 
END DummyFeld; 

PROCEDURE Hash(Schluessel : ARRAY OF CHAR) : CARDINAL; 

VAR i, summe : CARDINAL; 

BEGIN 

summe : = 0; 
i : = 0; 

WHILE (i <= HIGH(Schluessel)) AND (Schluessel[i] # OC) DO 
INC(summe, 0RD(Schluessel[i])); 

INC(i) 

END; 

RETURN summe MOD prim 
END Hash; 

PROCEDURE Einfuegen(Element : Verbund); 

VAR h,d : CARDINAL; 
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BEGIN 

d := 1; h : = Hash(Element.Schluessel); 

WHILE NOT (feld[h].Schluessel[0] = OC) DO 
INC(h, d); INC(d,2); 

IE h >= prim THEN h := h - prim END; 

IE d = prim THEN HALT END; 

END; 

feld[h] := Element 
END Einfuegen; 

PROCEDÜRE Suchen(VAR Element : Verbund) : BOOLEAN; 

VAR h,d : CARDINAL; 

BEGIN 

d := 1; h : = Hash(Element. Schluessel); 

LOOP 

IE Strings. StrEqual(feld[h].Schluessel, Element. Schluessel) THEN 

Element := feldfh]; RETURN TRUE; EXIT END; (* gefunden *) 

INC(h,d); INC(d,2); (* quadr. Sondieren *) 

IE h >= prim THEN h := h - prim END; 

IE d = prim THEN RETURN EALSE; EXIT END; 

END; 

END Suchen; 

PROCEDÜRE EeldZufaelligBelegen; 

VAR i,j : CARDINAL; 

BEGIN 

Randomize(OL); 

EOR i := 0 TO max - (max DIV 10) DO (* ca 10% des Feldes bleibt frei *) 

(* Feld mit Zufallsstrings belegen *) 
FOR j := 0 TO 3 DO Element.Schluessel[j] := CHR(RandomCard(65,90)) END; 
Einfuegen(Element); 

END; 

END EeldZufaelligBelegen; 

PROCEDÜRE FeldDrucken; 

VAR i : [0..max]; 

BEGIN 

EOR i := 0 TO max DO WriteCard(i, 3); 

IE feld[i].Schluessel[0] = OC THEN WriteString(”-”); 

ELSE WriteString(feld[i].Schluessel); WriteString(” ”) 

END 

END 


(* Platz besetzt *) 
(* quadr. Sondieren *) 

(* Feldüberlauf *) 


END FeldDrucken; 
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BEGIN 

DummyFelcL; 

FeldZufaelligBelegen; 

FeldDrucken; 

LOOP 

WriteLn; WriteString(”Nach welchem Schluessel suchen (RET = Ende) ”); 
ReadString(Element.Schluessel); 

IF Element.Schluessel[0] = OC THEN EXIT END; 

IF Suchen(Eleraent) THEN 

WriteString(”gefunden --> ”); WriteString(Element.Schluessel) 

ELSE 

WriteString(”Es ist kein Element mit diesem Schlüssel gespeichert!”) 
END; 

END; 

END HashDemo. 


Das Programm demonstriert das Einfügen von Schlüsseln - hier Zufallszeichenketten - sowie 
das anschließende Suchen. 

Das Löschen eines Elementes feld[ i ] geschieht einfach, indem man es durch Zuweisen des 
leeren Strings ”” als »leer« markiert (feld[i]. Schluessel : = ””)• 

Statt unserer Hash-Funktion kann man auch eine beliebig andere Hash-Funktion benutzen; 
Hauptsache, sie liefert bei dem selben Schlüssel immer den selben und sonst möglichst einen 
anderen Wert. 

Insgesamt sehen wir, daß Hashen ein sehr einfaches und effizientes Verfahren ist. Es kommt in 
vielen Fällen der Praxis zu Anwendung. 

Noch etwas Kritisches: Wenn man nur Daten abspeichern und sie wiederfinden will - was ei¬ 
nen häufigen Anwendungsfall darstellt -, ist Hashen ideal. Problematisch wird es aber, wenn 
das gesamte Feld sortiert ausgegeben werden soll. 

Abschließend noch eine andere Möglichkeit der Kollisionsauflösung, f eld sei ein Feld von 
Stapeln. Soll ein Datensatz mit dem Hash-Wert heingefügt werden, fügt man ihn einfach in 
den Stapel feld[h] ein. 

Kollisionen stören so nicht mehr, da auf jeden Stapel beliebig viele Elemente abgelegt werden 
können. Aber wir wollten ja hier einmal etwas ohne Zeiger schreiben ... 
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Bild 2.11: Feld von Stapeln 
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Kapitel 3 


Der 68000-Assembler 
unter Modula-2 
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Der 68000-Assembler unter Modula-2 


»Pfui«, werden sich einige ab wenden, »Assemblerroutinen mitten in Modula-Programmen? 
Warum soll man sich in die Niederungen der Maschine herablassen, wo Modula doch so flexi¬ 
bel ist?« Stimmt eigentlich, sehen wir uns dazu das folgende Beispiel an: 

PROCEDURE AusTausch(VAR varl, var2: ARRAY OF BYTE); 

VAR hilf : BYTE; 

i : CARDINAL; 

BEGIN 

FOR i := 0 TO HIGH(varl) DO 

hilf := varl[i]; varlfi] := var2[i]; var2[i] := hilf 
END 

END AusTausch; 

Diese Prozedur tauscht zwei Variablen varl und var2 aus und wird zum Beispiel beim 
Quicksort-Algorithmus gebraucht. Dabei können varl und var2 von beliebigem Datentyp 
sein. Schön einfach und flexibel, vom Modula-Standpunkt aus. 

Doch machen wir uns einmal klar, was der Prozessor beim Abarbeiten des Schleifenrumpfes 
leisten muß. Dazu muß man wissen, wie der Motorola-68000-Prozessor, das Herz unseres 
Ataris, im Prinzip arbeitet. 

Der Motorola 68000 

Dieser Prozessor hat 16 interne Speicher für 32 Bit, sogenannte Register, und zwar acht »Da¬ 
tenregister« DO bis D7 zum Speichern von Daten und acht Adreßregister A0 bis A7 zur Auf¬ 
nahme von Adressen. Die Datenregister können mit 8 Bit, 16 Bit oder 32 Bit geladen werden; 
das paßt genau für die Modula-Datentypen CHAR, CARDINAL und LONGCARD. Die Adreßregi¬ 
ster sind 32 Bit (4 Byte) breit. Intern werden davon nur 24 Bit benutzt. Damit ergeben sich 16 
Mbyte mögliche Adressen, das dürfte fürs erste reichen... 
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Bild 3.1: Daten - und Adreßregister des MC 68000 
Die Abarbeitung der obigen Zuweisungskette 

hilf := varl[i]; 
varl[i] := varl[i]; 
varl[i] := hilf 

geschieht - wenn der Compiler nicht besonders intelligent ist - nun folgendermaßen: 
hilf: = varl [ i ]: 

1. Die Adresse von varl [ i ] wird berechnet. 

2. Der Wert varl [ i ] wird in ein Datenregister geladen. 

3. Der Inhalt des Datenregisters wird nach hilf geladen. 

varl[i]:= var2[i]: 

4. Die Adresse von var2 [ i ] wird berechnet. 

5. Der Wert var2 [ i ] wird in ein Datenregister geladen. 

6. Die Adresse von varl [ i ] wird erneut berechnet. 

7. Der Inhalt des Datenregisters wird an diese Adresse geladen. 
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var2[i]: = hilf: 

8. Der Wert von hilf wird in ein Datenregister geladen. 

9. Die Adresse von var2 [ i ] wird erneut berechnet. 

10. Der Inhalt des Datenregisters wird an diese Adresse geladen. 

Gegebenenfalls wird bei jedem Anweisungsblock noch geprüft, ob der Index i für var2 [ i ] 
bzw. varl [ i ] zulässig ist (nennt sich »ABC« array bound check- »Feldindexgrenzenüber¬ 
prüfung«). 

So betrachtet, klingt es doch recht kompliziert, insbesondere ist der Umweg über die Variable 
hilf recht unflott. Effizienter wäre es, wenn varlfi] und var2[i] in zwei verschiedene 
Datenregister geladen und dann vertauscht zurückgespeichert werden. 

Wenn man den Austauschalgorithmus mit dem Ziel angeht, ihn so zu lösen, daß er optimal 
schnell arbeitet, muß man dieses Programmstück direkt in Assembler programmieren. Hierzu 
geben wir zunächst einen Überblick über den Befehlsvorrat des Motorola 68000-Prozessors, 
dem Herzstück des Atari-ST. Es geht also jetzt ans Eingemachte! 


3.1 Kurzeinführung in die Befehle des Motorola-68000 

Insgesamt verfügt dieser Prozessor über 56 verschiedene Operationen, die man folgenderma¬ 
ßen einteilen kann: 

1. Datentransportbefehle (z. B. M0VE) 

2. Arithmetische Befehle (z. B. SUB) 

3. Bitmanipulationsbefehle (z. B. BSET) 

4. Vergleichs- und Testbefehle (z. B. CMP) 

5. Schiebebefehle (z. B. LSR) 

6. Logische Befehle (z. B. AND) 

7. Programmsteuerbefehle (z. B. BRA) 

8. Systemaufrufe (z. B. TRAP) 

Wir benötigen für unsere Austausch-Prozedur sowie einige andere kleine, brauchbare Proze¬ 
duren von den 56 Befehlen nur die im folgenden aufgeführten. Hierbei steht ». s« für 
».B« (BYTE) ,». w« (WORD) oder ». L« (L0NGW0RD) , je nachdem, ob der Operand 1 Byte, 2 
Byte oder 4 Byte umfaßt. Fehlt diese Angabe, wird ». W« angenommen: M0VE DO, Dl ent¬ 
spricht MOVE. w DO, Dl und kopiert ein WORD (l6Bit). 
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Aus der 1. Gruppe (Datentransportbefehle): 

MOVE. s <quelle>, <ziel> move , »transportieren« 

Hier wird <quelle> nach <ziel> kopiert. 

In Modula etwa: <ziel> : = <quelle> 

CLR. s Dn clear, »löschen« 

setzt Datenregister n auf 0. 

In Modula etwa: Dn : = 0 

Aus der 2. Gruppe (arithmetische Befehle): 

ADDQ. s#k, <ziel> add quick , »schnelle Addition« 

Die Konstante k wird zu <ziel> zuaddiert; k = 1..8 
In Modula etwa: INC(Dn, k) 

SUBQ. s#k, <zi el> subtract quick , »schnelle Subtraktion« 

Die Konstante k wird von <ziel> abgezogen; k = 1..8 
In Modula etwa: DEC (Dn, d) 

Aus der 5. Gruppe (Schiebebefehle): 

LSL. s Dn, Dm logical shift left , »Verschiebung nach rechts« 

Die Bits im Datenregister Dm werden um so viele Stellen nach links verschoben, 
wie Dn angibt. 

Etwa vergleichbar mit: Dm : = Dm*2 Dn 

LSR. s Dn, Dm logical shift right , »Verschiebung nach links« 

Die Bits im Datenregister Dm werden um so viele Stelle nach rechts verschoben, 
wie Dn angibt. 

Etwa vergleichbar mit: Dm : = Dm DlV2 Dn 

Aus der 6. Gruppe (logische Befehle): 

AND. s Dn, Dm and , logisches »UND« 

Das Datenregister Dm wird mit dem Register Dn bitweise mit »UND« ver¬ 
knüpft. Das Ergebnis steht anschließend in Dm. 

0R. s Dn, Dm or, logisches »ODER« 

Das Datenregister Dm wird mit dem Register Dn bitweise mit »ODER« ver¬ 
knüpft. Das Ergebnis steht anschließend in Dm. 

EOR. s Dn, Dm exclusive or , »entweder ODER« 

Das Datenregister Dm wird mit dem Register Dn bitweise mit »exclusive- 
ODER« verknüpft. Das Ergebnis steht anschließend in Dm. 



290 


Assembler-Anweisungen in Modula-2-Routinen 


NOT. s Dn not , »nicht« (Komplement) 

Die Einsen in diesem Datenregister werden zu Nullen und umgekehrt. 

Aus der 7. Gruppe (Programmsteuerbefehle): 

BRA <Label> brauch always, »verzweigen« 

Normalerweise wird ein Assemblerprogramm in der Reihenfolge seiner Befehle 
abgearbeitet. Mit BRA ist der »Sprung« zu einer anderen Programmstelle mög¬ 
lich, die mit einer Sprungmarke <Label> gekennzeichnet ist. 

DBF Dn, <Label> decrement and brauch , »Dekrement und Sprung« 

Erniedrigt Dn (als WORD !) um eins und springt dann nach <Labcl >, falls Dn nicht 
vorher Null war. Eignet sich zur Implementation von schnellen Schleifen. 

Aus der 8. Gruppe (Systemaufrufe): 

TRAP #n trap , »Falle«; Falltür zum Betriebssystem 

Der Prozessor startet eine Ausnahmeprozedur. Bei dem Atari sind: 


TRAP 

#l: 

GEMDOS-Aufruf 

TRAP 

#2: 

GEM-Aufruf (VDI,AES) 

TRAP 

#13: 

BIOS-Aufruf 

TRAP 

#14: 

XBIOS-Aufruf 


Die Besprechung sämtlicher 56 Befehle sprengt den Rahmen dieses Buches, zumal die einzel¬ 
nen Operationen mit bis zu 14 (!) verschiedenen Adressierungsarten vorgenommen werden 
können. Damit sind die Argumente der Befehle gemeint. Unsere Liste beschränkt sich auf die¬ 
jenigen Adressierungen, die wir im folgenden benötigen. Wer sich hier Weiterarbeiten will, 
dem sei das Buch [V] empfohlen; zur Orientierung und zum Nachschlagen verweisen wir auf 
Anhang C. 


3.2 Assembler-Anweisungen in Modula-2-Routinen 

Wie kann man nun in Assembler geschriebene Routinen in seine Modula-Texte einbinden? Bei 
TDI- und SPC-Modula geht man wie folgt vor: 

Man tippt die Routinen in ein gesondertes Assemblerprogramm und testet sie dort aus. Nach 
dem Assemblieren erhält man reinen Maschinencode, der aus 16-Bit-Instruktionen besteht, 
vom Modula Standpunkt aus sind das CARDINAL-Zahlen. Nun schreibt man ein 
Modula-Programm und setzt diese Zahlen in eine beliebig lange Parameterliste der Prozedur 
CODE (bei TDI) oder INLINE (bei SPC-Modula), die jeweils aus SYSTEM importiert werden. 
In Hänisch-Modula wird für jedes Assemblerwort eine CODE- oder LOAD- Anweisung aufgeru- 
fen werden (CODE und LOAD sind Prozeduren aus SYSTEM). 
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Deutlich eleganter geht das nun bei Megamax-Modula und MSM2. Dort kann man direkt 
Assembleranweisungen, also die oben angegebene Mnemonic-Form der Befehle, in den Mo- 
dula-Text einfügen. Diese Stellen werden in Megamax-Modula von ASSEMBLER und END, 
bei MSM2 von (*$A+*) und (*$A-*) geklammert: 

Bei MSM2: 

(*$A+*) 

<Assemb1er-Anweisung> 

<Assembler-Anweisung> 

<. . . > 

(*tf A-*); 

Bei Megamax-Modula: 

ASSEMBLER 

<Assembler-Anweisung> 

<Assembler-Anweisung> 

<. . . > 

END; 

Assembler-Anweisungen gehören bei Megamax-Modula und MSM2 zum Sprachumfang. 
Nun muß man nur noch wissen, wie der Assemblerteil mit dem übrigem Modula kommuni¬ 
ziert, insbesondere wie auf Variablen und Parameter von Prozeduren zugegriffen wird. Varia¬ 
blen kann man direkt ansprechen: 

VAR Faktor,Produkt: CARDINAL; 

BEGIN (* Assembler in MSM2 *) 

(*$ A+*) 

MOVE.W Faktor,DO 

LSL #3, DO 

MOVE.W DO,Produkt 
(*« A-*); 


VAR Faktor,Produkt: CARDINAL; 

BEGIN (* Assembler in Megamax-Modula *) 
ASSEMBLER 

MOVE.W Faktor,DO 

LSL #3,DO 

MOVE.W DO,Produkt 

END; 
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Nun, eigentlich ist es wirklich nicht nötig, in Modula auf Assembler zurückzugreifen. Aber 
wenn man nicht vor hat, seine Programme noch auf anderen Systemen zu verwenden und 
wenn es wirklich einmal um eine zeitkritische Anwendung geht, sollte der Zugang zum 
Assembler nicht verwehrt bleiben. Guter Stil ist es aber, die Assemblerteile in eigene Prozedu¬ 
ren zu packen und diese in ein gesondertes Modul zu stecken. 

Damit nun für einen Prozeduraufruf nicht mehr zuviel Zeit für den nun nicht mehr nötigen 
Parameter-Übernahmemechanismus vergeudet wird, läßt sich dieser in Megamax-Modula 
mit der Option (*$ L-*) abschalten. Die Parameter muß man nun »von Hand« abholen. Sie 
befinden sich auf einem gesonderten Stack, der über das Register A3 verwaltet wird. Wegen 
dieser Besonderheiten folgen die weiteren Beispiele in Megamax-Modula: 

PROCEDURE p(nl,n2: CARDINAL, n3:LONGCARD); 

(*$ L-*) 

BEGIN 

ASSEMBLER 


MOVE.L 

-(A3),DO 

; n3 

(4 Byte) 

jetzt 

in 

DO 

MOVE.W 

-(A3),Dl 

; n2 

(2 Byte) 

jetzt 

in 

Dl 

MOVE.W 

<. . . > 

-(A3),D2 

; nl 

(2 Byte) 

jetzt 

in 

D2 


END 
END p; 

(*$ L+*) 

Man erkennt hier folgendes: 

1. Die Abschaltung der automatischen Parameter-Übernahme (*$ L-*) wird mit 
(*$ L+*) wieder eingeschaltet. 

2. Hinter Assembleranweisungen können in der selben Zeile Kommentare folgen. Sie werden 
durch ein Semikolon eingeleitet und reichen bis zum Zeilenende. 

3. Mit dem Befehl 
MOVE.L -(A3),DO 

wird ein Parameter von dem Parameter-Stack abgeholt und nach DO geladen. Die Klam- 
merung der Quelle »- ( A3 )« deutet an, daß der Operand nicht der Wert des Registers A3 
selbst ist; vielmehr enthält A3 die Adresse des Operanden (indirekte Adressierung). Das 
Minuszeichen besagt, daß die Adresse vor der Verarbeitung noch zu erniedrigen ist und 
zwar um 4 bei einem L0NGW0RD (L), 2 bei einem WORD (W)und 1 bei einem BYTE 
(B) . Man spricht von »Indirekter Adressierung mit Predekrement«. 
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4. Die Parameter liegen in umgekehrter Reihenfolge auf dem Stack, also das letzte Argument 
der Parameterliste muß zuerst abgeholt werden. 

5. Beider (*$ L-* ) -Option müssen alle Parameter abgeholt werden, die in der Parameterli¬ 
ste stehen, selbst wenn sie nicht benötigt werden! Sonst stimmt der Parameterstack (A3) 
nicht mehr. 

Bei VAR-Parametern wird die Adresse (4 Byte) übergeben, unabhängig von der Größe des 

Parameter: 


PROCEDURE p (VAR Zeichen: CHAR); 

(** L-*) 

BEGIN 

ASSEMBLER 

MOVE.L -(A3),A0 ; Adresse (4 Byte) von Zeichen in AO 

MOVE.B (AO),DO ; ’ Zeichen’ jetzt in DO 

<. . . > 

MOVE.B DO,(AO) ; Verändert den VAR-Parameter ‘Zeichen’ 

END 
END p; 

(*$ L+*) 


Bei einem offenem Feld als Werte- oder VAR-Parameter wird immer die Adresse und an¬ 
schließend der HIGH-Wert übergeben; man muß also quasi zwei Parameter abholen: 

PROCEDURE p(feld: ARRAY OE BYTE); 

(*$ L-*) 

BEGIN 

ASSEMBLER 

MO VE. W -(A3), DO 
MOVE.L -(A3),AO 

END 
END p; 

(*$ L+*) 


<. . . > 


; HIGH(feld) nach DO 
; Adresse von ’feld’ nach AO 
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3.2.1 Modul »LowLevel« für speicherbezogene Operationen 

Der erste Modul stellt Prozeduren für das schnelle Kopieren, Austauschen und Füllen von 
Variablen, sprich Speicherbereichen bereit. Es wird also an das Eingangsbeispiel zu diesem 
Kapitel angeknüpft. Die Prozedur CopyN wird bereits in Kapitel 2.1 benutzt. Zunächst der 
Definitionsmodul: 

DEFINITION MODULE LowLevel; 

FROM SYSTEM IMPORT ADDRESS, BYTE; 

PROCEDURE CopyVar(VAR quelle,ziel: ARRAY OF BYTE); 

(* 

* Kopiert ’quelle’ nach ’ ziel*; diese Variabein 

* müssen vom selben Variablentyp sein. 

*) 

PROCEDURE CopyN(AdrQuelle,AdrZiel: ADDRESS; anzahl: LONGCARD); 

(* 

* Kopiert einen Speicherbereich der Größe *anzahl? Bytes. Der 

* Quellbereich beginnt bei ’AdrQuelle’, der Zielbereich bei ’AdrZiel’. 

*) 

PROCEDURE SwapN(ptrA,ptrB: ADDRESS; anzahl: LONGCARD); 

(* 

* Vertauscht die Speicherbereiche der Größe ’anzahl’ Bytes, 

* auf die ptrA und ptrB zeigen. 

*) 

PROCEDURE FillBytes(VAR Feld: ARRAY OF BYTE; FuellByte: BYTE); 

(* 

* Fuellt das gesamte ’Feld’ mit ’FuellByte’. 

*) 

END LowLevel. 


Der Implementationsmodul ist ausreichend kommentiert: 

IMPLEMENTATION MODULE LowLevel; 

FROM SYSTEM IMPORT ADDRESS, BYTE; 


(*$ L-*) 
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PROCEDURE CopyVar(VAR quelle,zi 
BEGIN 

ASSEMBLER 

MOVE.W -(A3),Dl ; 

MOVE.L -(A3), Al ; 

MOVE.W -(A3),DO ; 

MOVE. L -(A3),AO ; 

Schleife: 


el: ARRAY OP BYTE); 

HIGH(ziel) 

Adresse von ziel 
HIGH(quelle) 
Adresse von quelle 


MOVE.B (A0)+,(A1)+ ; Byte kopieren, dann A0,A1 erhöhen 

DBP Dl,Schleife ; zu * Schleife’, wenn nicht fertig 

END 

END CopyVar; 

PROCEDURE CopyN(AdrQuelle, AdrZiel: ADDRESS; anzahl: LONGCARD); 


BEGIN 

ASSEMBLER 

MOVE.L 

-(A3), Dl 

; anzahl -> Dl 

MO VE. L 

-(A3),Al 

; AdrZiel -> Al 

MO VE. L 

-(A3),AO 

; AdrQuelle -> AO 

BRA 

ErsteMal 


Schleife: 

MOVE.B 

(AO)+,(Al)+ 

; Ein Byte Quelle -> Ziel 

ErsteMal: 

DBP 

Dl,Schleife 

; Schleife fertig? 

END 

END CopyN; 




PROCEDURE SwapN(ptrA, ptrB: ADDRESS; anzahl: LONGCARD); 
BEGIN 

ASSEMBLER 


MOVE. L 

-(A3),Dl 

; anzahl -> Dl (Schleifenzähler) 

MOVE.L 

-(A3), Al 

; Adresse ptrB -> Al 

MOVE.L 

-(A3),AO 

; Adresse ptrA -> AO 

BRA 

ErsteMal 


Schleife: 

MOVE.B 

(AO),DO 

; Byte von ptrA -> DO (Hilfsspeicher) 

MOVE.B 

(Al),(AO)+ 

; Byte von ptrB -> ptrA (und ptrA erhöhen) 

MOVE.B 

DO,(Al)+ 

; Byte von DO -> ptrB (und ptrB erhöhen) 

ErsteMal: 

DBP 

Dl,Schleife 

; Schleife fertig? 
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END 

END SwapN; 
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PROCEDURE EillBytes(VAR Feld: ARRAY OE BYTE; FuellByte: BYTE); 
BEGIN 


ASSEMBLER 


SUBQ.L #1, A3 


A3 korrigieren, da nächster Parameter BYTE 


MOVE.B -(A3),DO 
MOVE. W -(A3),Dl 
MOVE.L -(A3),AO 


FuellByte -> DO 
HIGH(Feld) -> Dl 
Addr(Feld) -> AO 


Schleife: 

MOVE.B DO,(AO)+ 

DBF Dl,Schleife 


ein Byte von DO -> Feld, AO erhoehen 

mit nächstem Byte füllen, wenn nicht fertig 


END 

END FillBytes; 

(*$ L+*) 

END LowLevel. 

Das folgende kleine Demonstrationsprogramm zeigt eine Anwendung des LowLevel- 
Moduls. 

MODULE LowLevelTest; 

PROM InOut IMPORT Read, WriteString, WriteLn; 

FROM LowLevel IMPORT FillBytes, CopyVar; 

VAR i : CARDINAL; 

sl,s2 : ARRAY[0..19] OF CHAR; 

taste : CHAR; 

BEGIN 

FillBytes(sl,”X”); 

WriteString(”String ’sl’ mit 20 ’ X’ füllen: ”); 

FillBytes(sl,”X”); WriteString(sl); WriteLn; 

WriteString(”String ’s2’ mit 10 ’U’ füllen: ”); 

FillBytes(s2,”U”); s2[10] := OC; WriteString(s2); WriteLn; 

WriteString(”Nun sl nach s2 kopieren! ”); WriteLn; 

CopyVar(sl,s2); 

WriteString(”sl: ”); WriteString(sl); WriteString(” s2: ”■); WriteString(s2); 
Read(taste) 

END LowLevelTest. 
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3.2.2 Ein Modul für Bitmanipulationen 

Vielleicht kennen Sie von Turbo Pascal die logischen Verknüpfungen AND, OR und XOR zwi¬ 
schen ganzen Zahlen. Sie arbeiten bitweise, so ergibt zum Beispiel 13 AND 7 das Ergebnis 5, 
denn 

-^dezimal = ^ ^ ^dual 

7 -HIT 

'dezimal - XJ " L dual 

13 AND 7 = 5 dezimal = 101 dual 

Es handelt sich also um bitweise Manipulationen, die man gelegentlich brauchen kann. In die¬ 
sen Kontext gehört auch NOT (Bildung des Einer-Komplements = Invertierung der Nullen 
und Einsen) und die Prozeduren SHR und SHL (Verschieben des Bitmusters nach rechts bzw 
links, was bei Zahlen einer Division durch 2 bzw. eine Multiplikation mit 2 bedeutet. 

Ist i eine CARDINAL-Variable und O^nglö, so kann man 

SHL(i, n) Statt i*m (m = 2 n ) 

SHR(i, n) Statt i DIV m (m = 2 n ) 

AND( i, n-1 ) Statt i MOD m (m = 2 n ) 

benutzen. Wir fassen diese Prozeduren als ein weiteres Beispiel zur Nutzung der Maschinen¬ 
sprache in den Modul Bitmanipulation zusammen: 

DEFINITION MODULE Bitmanipulation; 

EROM SYSTEM IMPORT WORD; 

PROCEDURE shl(VAR c: WORD; schub: CARDINAL); 

(* schiebt c um schub Bits nach links *) 

PROCEDURE shr(VAR c: WORD; schub: CARDINAL); 

(* schiebt c um schub Bits nach rechts *) 

PROCEDURE and(a,b: WORD) : WORD; 

(* bitweises AND *) 

PROCEDURE or(a,b:WORD): WORD; 

(* bitweises OR *) 

PROCEDURE xor(a,b: WORD) : WORD; 

(* bitweises XOR *) 
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PROCEDURE not(a:WORD): WORD; 

(* Einerkomplement *) 

END Bitmanipulation. 


IMPLEMENTATION MODÜLE Bitraanipulation; 

PROM SYSTEM IMPORT WORD; 

(*$ L-*) 

PROCEDURE shl(VAR c: WORD; 

BEGIN 

ASSEMBLER 

schub 

CARDINAL); 

MOVE -(A3),Dl 


Dl: schub 

MOVE.L -(A3),AO 


AO: ADR(c) 

MOVE (AO),DO 


DO: c 

LSL Dl,DO 


DO := DO shr Dl 

MOVE DO, (AO) 

END 

END shl; 


c zurückschreiben 

PROCEDURE shr(VAR c: WORD; 

BEGIN 

ASSEMBLER 

s chub: 

: CARDINAL); 

MOVE -(A3),Dl 


Dl: schub 

MOVE.L -(A3),AO 


AO: ADR(c) 

MOVE (AO),DO 


DO: c 

LSR Dl,DO 


DO := DO shr Dl 

MOVE DO,(AO) 

END 

END shr; 


c zurückschreiben 

PROCEDURE and(a,b: WORD) : 

BEGIN 

ASSEMBLER 

WORD; 


MOVE -(A3),Dl 


Dl: b 

MOVE -(A3),DO 


DO: a 

AND Dl, DO 


DO := DO AND Dl 

MOVE DO,(A3)+ 

END 

END and; 


Punktionswert zurückgeben 
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PROCEDURE or(a, 

b:WORD): WORD; 


BEGIN 

ASSEMBLER 

MOVE 

-(A3),Dl 

Dl: b 

MOVE 

-(A3),DO 

DO: a 

OR 

Dl, DO 

DO : = DO OR Dl 

MOVE 

DO,(A3)+ 

Punktionswert zurückgeben 

END 

END or; 



PROCEDURE xor(a 

,b: WORD) : WORD; 


BEGIN 

ASSEMBLER 

MOVE 

-(A3),Dl 

Dl: b 

MOVE 

-(A3),DO 

DO: a 

EOR 

Dl, DO 

XOR heisst beim 68000 EOR 

MOVE 

DO,(A3)+ 

Punktionswert zurückgeben 


END 

END xor; 


PROCEDURE not(a:WORD): WORD; 

BEGIN 

ASSEMBLER 

NOT -2(A3) ; Invertiert a auf dem Stack 

END 

END not; 

(*$ L+*) 

END Bitmanipulation. 


Es sei noch erwähnt, daß man die Prozeduren and, or, xor und not in Modula unter Ver¬ 
wendung von BITSET schreiben kann. Das gilt nicht für shr und shl. SPC-Modula hat im 
Pseudomodul SYSTEM eine Prozedur SHIFT, die sowohl shr als auch shl abdeckt und auf 
allen Typen arbeitet. Zum Abschluß dieses Einblicks in die Assemblerprogrammierung brin¬ 
gen wir noch ein kleines Beispiel, was sich mit Kryptographie (= Verschlüsselungsverfahren) 
befaßt. 

Nehmen wir an, Sie wollen ein Adventure-Spiel schreiben. Sicherlich werden hier Strings Vor¬ 
kommen, die die Auflösung ihres sorgfältig programmierten Spiels verraten könnten, wenn 
sich ein cleverer Hacker ihr Programm mit einem Disk-Monitor ansieht. Das gleiche gilt für 
den Schutz von jeglichen Copyright-Strings oder Firmenbezeichnungen usw. im Code-File. 
Kodieren Sie diese verräterischen Texte doch einfach, laden den Code in Ihr Programm ein 
und dekodieren ihn dort wieder. 
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Bei der vorgestellten Lösung wird der Code als ARRAY OP BYTE übergeben. Der Witz ist 
nun, daß ein und dieselbe Prozedur das Kodieren und Dekodieren übernimmt. Hier nun das 
Demonstrationsprogramm: 

MODULE VerschluesselnEntschluesseln;(* Zeigt eine Anw. der Bitmanipulationen *) 

PROM SYSTEM IMPORT BYTE; 

PROM Bitmanipulation IMPORT xor, and; 

PROM InOut IMPORT WriteString, ReadString, Read, WriteLn, WriteCard; 

PROM Strings IMPORT Length; 

VAR text : ARRAY [0. . 79] 0F CHAR; 

ch : CHAR; 

i,laenge : CARDINAL; 

PROCEDURE Codiere(VAR geheim : ARRAY OP BYTE); 

CONST kl = 123; 
k2 = 25; 

VAR i,n : CARDINAL; 

BEGIN 
n : = kl; 

POR i: =0 TO HIGH(geheim) DO 
n : = CARDINAL(and(n*k2, 255)); 
geheim[i] := SHORT(xor(LONG(geheim[i]), n)); 

END 

END Codiere; 

BEGIN 

WriteString(”Verschlüsseln und entschlüsseln”); 

WriteLn; WriteLn; 

WriteString(”Eingabetext: ”); ReadString(text); 
laenge : = Length(text); 

WriteLn; 

Codiere(text); 

WriteString(”Verschlüsselt: ”); WriteLn; 

POR i:= 1 TO laenge DO WriteCard(ORD(text[i]), 4) END; 

Codiere(text); 

WriteLn; WriteString(”Nun wieder entschlüsselt: ”); WriteLn; 

WriteString(text); 

WriteLn; Read(ch) 

END VerschluesselnEntschluesseln. 
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3.3 Zugriff auf Systemvariablen 

Im Speicherbereich mit den Adressen von 400H bis 512H stehen beim Atari ST die sogenann¬ 
ten Systemvariablen, mit denen das Betriebssystem arbeitet. Sie finden eine ausführliche Liste 
der Bedeutung dieser Variablen in jedem Buch über das Betriebssystem des Atari ST (z. B. 
[D],[G]). 

Diese System-Variablen liegen in einem geschützten Speicherbereich, auf den nur im Supervi¬ 
sor-Modus (das ist ein bestimmter Zustand des 68000er Prozessors) zugegriffen werden kann. 
Ihre Programme laufen aber sicherheitshalber im User-Modus ab, wo ein Zugriff auf diesen 
Bereich einen »Bus error« verursacht. Ansonsten hätte jeder versehentliche Zugriff über einen 
NIL-Pointer (der meist auf Adresse OH landet) verheerende Folgen. 

Einige Modula-Systeme enthalten in einem Modul GEMDOSeine Prozedur Super, mit der sich 
der Supervisor-Modus einschalten läßt. Andere Systeme bieten diese Funktion sicherheits¬ 
halber nicht an. Wir bringen Sie daher in einem Modul Supervisor. 

DEFINITION MODULE Supervisor; 

(* -—----- — - - -- — - - ~— — -- 

* Der Supervisor-Modus sollte nur in Ausnahmefällen eingeschaltet 

* werden, wie zum Beispiel zum Auslesen von Systemvariablen (diese 

* sind nur im Supervisor-Modus lesbar). Er sollte dabei nur so 

* kurz wie unbedingt nötig eingeschaltet bleiben. Danach ist er 

* sobald wie möglich wieder abzuschalten! 

* -- ----- -* ) 

PROCEDURE SuperVisorEin; (* Einschalten des Supervisor-Modus *) 

PROCEDÜRE SuperVisorAus; (* Zurückschalten in den Normalmodus *) 

END Supervisor. 


Im Implementationsmodul wird die GEMDOS-Funktion Nr. 32 »get/set Supervisor mode« 
benötigt. Mit TRAP #1 wird GEMDOS aufgerufen, die Funktionsnummer wird zuvor auf 
den Stack (A7) gelegt. 

IMPLEMENTATION MODULE Supervisor; 

FROM SYSTEM IMPORT ADDRESS; 

VAR 

AlterStack: ADDRESS; (* Zwischenspeicher für den Stack *) 


(*$ L-*) 
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PROCEDURE SuperVisorEin; 
BEGIN 

ASSEMBLER 


CLR. L 

- (A7) 

MOVE.W 

#32,-(A7) 

TRAP 

#1 

ADDQ.L 

#6, A7 

MOVE.L 

DO,AlterStack 

END 


END SuperVisorEin; 


PROCEDURE SuperVisorAus; 

BEGIN 


ASSEMBLER 


MOVE.L 

AlterStack,~(A7) 

MOVE.W 

#32,-(A7) 

TRAP 

#1 

ADDQ.L 

#6, A7 


END 

END SuperVisorAus; 


(*$ L+*) 

END Supervisor. 


Parameter 0: Setze Supervisor-Mode 
GEMDOS-Funktions-Nummer für ’Super’ 
GEMDOS aufrufen 
Stack korrigieren 

Vorherigen Supervisor-Stack merken 


Supervisor-Stack: zum restaurieren 
GEMDOS-Punktions-Nummer für ’Super’ 
GEMDOS aufrufen 
Stack Korrigieren 


3.3.1 Bau einer Stoppuhr 

Als Anwendung des Moduls Supervisor greifen wir auf die System-Variable »_hz_200« zu. 
Dies entspricht einer LONGCARD-Variablen, die in Abständen von 5 ms (Millisekunden) 
vom letzten Reset an hochgezählt wird. Damit kann man eine Stoppuhr bauen, um zum Bei¬ 
spiel Laufzeiten von Prozeduren zu messen. 

Die Variable »_hz_200« steht an der Adresse 4BAH. Die Prozedur St oppuhr. startliest den 
augenblicklichen Wert. Stoppuhr. Lesen liest ihn zu einen späteren Zeitpunkt und berech¬ 
net die Differenz seit dem letzten Aufruf von Start, multipliziert sie mit 5 und erhält damit die 
verstrichene Zeit in Millisekunden. Die Prozedur Warten veranlaßt eine Warteschleife, was 
gelegentlich in Programmen nützlich ist. 

DEFINITION MODULE Stoppuhr; 

PROCEDURE Start; (* zum Einschalten der Stoppuhr *) 

PROCEDURE Lesen : LONGCARD; (* gibt Zeit nach dem Einschalten in ms *) 

PROCEDURE Warten(Dauer : LONGCARD); (* Wartet Dauer * 0.005 s *) 

END Stoppuhr. 
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Der Implementationsmodul ist auch ganz einfach: 

IMPLEMENTATION MODULE Stoppuhr; 

PROM Supervisor IMPORT SuperVisorEin, SuperVisorAus; 

VAR ZeitTakte : LONGCARD; 

hz200[4BAH] : LONGCARD; (* System Variable _hz_200, wird alle 5 ms erhöht *) 

PROCEDURE Start; 

BEGIN 

SuperVisorEin; 

ZeitTakte := hz200; 

SuperVisorAus; 

END Start; 

PROCEDURE Lesen : LONGCARD; (* gibt Zeit nach dem Einschalten in ms *) 

BEGIN 

SuperVisorEin; 

ZeitTakte := hz200-ZeitTakte; 

SuperVisorAus; 

RETURN ZeitTakte * 5L 
END Lesen; 

PROCEDURE Warten(Dauer : LONGCARD); 

VAR jetzt, spaeter : LONGCARD; 

BEGIN 

SuperVisorEin; 

jetzt := hz200; 

spaeter:= jetzt + Dauer; 

REPEAT UNTIL hz200 > spaeter; 

SuperVisorAus; 

END Warten; 

END Stoppuhr. 


Hier ein kleiner Testmodul. Vergleichen Sie die gemessenen Zeiten mit einer anderen Stopp¬ 
uhr. 

MODULE StoppuhrTest; 

PROM InOut IMPORT Read, WriteLn, WriteString, WriteCard; 

IMPORT Stoppuhr; 
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VAR taste : CHAR; 

BEGIN 

WriteLn; WriteString(”Taste drücken für Stoppuhr-Start”); 

Read(taste); 

Stoppuhr.Start; 

WriteLn; WriteString(”Taste drücken zum Stoppen”); 

Read(taste); 

WriteLn; WriteString(”Zeit(ms): ”); WriteCard(Stoppuhr. Lesen(),1); 
Read(taste); 

END StoppuhrTest. 


3.3.2 Schnelles Zeichnen, direkt auf den Bildschirm 

Wir greifen hier das Beispiel Kreis (Bresenham-Algorithmus) aus Kapitel 1.3.3 auf. Hier 
wurde ein Kreis auf dem Textbildschirm gezeichnet oder vielmehr durch das Zeichen »*« an¬ 
gedeutet. Nun schreiben wir - etwas unsauber - direkt in den Bildschirmspeicher; auch das 
geht in Modula! 

Dazu wird die Startadresse des Bildschirms benötigt, also die Adresse desjenigen Bytes, das 
der linken oberen Ecke des Bildschirms entspricht. Diese Adresse ist in der Systemvariablen 
»_v_bas_ad« gespeichert, die an der Speicherstelle 44EH steht. Der ersten Bildschirmzeile 
entsprechen dann die 80 Byte, die sich ab der Adresse befinden, die in _v_bas_ad steht. 80 
Byte entsprechen 640 Bit, die die Pixel einer Bildschirmzeile des monochromen Bildschirms 
darstellen (0 = weiß, 1 = schwarz). Von diesen 80-Byte-Zeilen haben wir insgesamt 400, die ein¬ 
fach mit aufsteigenden Adressen nacheinander gespeichert sind. Insgesamt sind für den Bild¬ 
schirm 32000 Byte (400 *80 Byte) reserviert. 

Wir benötigen eine Routine Pl o t ( x, y), die ein Pixel auf dem Bildschirm schwarz setzt. Dazu 
muß sie herausfinden, welches Bit sie in welchem Byte auf eins setzen muß. 

Die Umrechnung des Pixels (x, y) in die zugehörige Adresse geschieht so: 

• (x,y) -> 80y + x DIV 8 (das Byte) 

• 7- (x MOD 8) (das Bit innerhalb des Byte) 

In dem gefundenen Byte müssen alle anderen Bits erhalten bleiben, nur das gewünscht Bit soll 
gesetzt werden. Dies kann man in Modula elegant mit der Inklusion von Mengen lösen. Daher 
ist es zweckmäßig, den Bildschirm als Feld der Menge { 0 . . 7}aufzufassen. Das folgende 
kleine Beispielprogramm zeigt das Zeichnen eines Kreises und einer Linie. 
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Spalte x 


0 


639 

Byte 0 

80 Bytes pro Zeile 

Byte 79 


X 



y -► . Pixel (x,y) 


Byte 31920 


Byte 31999 


Bild 3.2: Atari-Bildschirm (monochrom) 

MODULE Grafik; 

PROM Supervisor IMPORT SuperVisorEin, SuperVisorAus; 

PROM Terminal IMPORT Write, Read; 

TYPE 

BBS = SET OF [0..7]; (* ByteBitSet *) 

BildschirmPtr = POINTER TO ARRAY [0..31999] OP BBS; (* Bildschirm-Array *) 

VAR 

Bildschirm : BildschirmPtr; 

PROCEDURE HoleBildschirmAdr; 

VAR 

VBasAdr[44EH] : BildschirmPtr; 

BEGIN 

SuperVisorEin; 

Bildschirm := VBasAdr; 

SuperVisorAus; 

END HoleBildschirmAdr; 


(* Anfang des BildschirraSpeichers *) 

(* *VBasAdr’ nur im Supervisor lesbar *) 
(* ... deshalb umkopieren *) 
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PROCEDURE Plot(x, y : INTEGER); 

BEGIN 

IF (0 <= x) & Cx <= 639) & (0 <= y) & (y <= 399 ) THEN (*Clipping *) 

INCL(BildschirnT [ y * 80 + x DIV 8 ], 7 -(x MOD 8)); 

END; 

END Plot; 

(*$ R- *) (* Bereichsüberprüfung aus, da r*r > MAX(INTEGER) werden kann *) 

PROCEDURE Kreis(xMitte,yMitte,r : INTEGER); 

VAR x,y,radiusHoch2 : INTEGER; 

BEGIN 

x := 0; y := r; rHoch2 := r * r; 

REPEAT 

Plot(xMitte+x, 

Plot(xMitte+y, 

Plot(xMitte+y, 

Plot(xMitte+x, 

Plot(xMitte-x, 

Plot(xMitte-y, 

Plot(xMitte-y, 

Plot(xMitte-x, 

INC(x); 

IF x*x + y*y - 
UNTIL x >= y; 

END Kreis; 

(* $ R+ *) 

VAR i : INTEGER; 

c : CHAR; 

BEGIN 

Write(33C); Write(”E”); (* Bildschirm löschen *) 

HoleBildschirmAdr; (* Lesen der Bildschirm-Start-Adresse für ’Plot’ *) 

Plot(320,200); 

FOR i: =0 TO 380 BY 20 DO Kreis(320,200,i) END; (* Kreise zeichnen *) 

Read(c); 

FOR i:=0 TO 399 DO Plot(i,i) END; (* Linie zeichnen *) 

Read(c) 

END Grafik. 

Das Zeichnen geschieht sehr schnell. Eine Beschleunigung kann man noch erreichen, wenn die 
langsamen Operatoren DIV und MOD durch Prozeduren aus dem Modul Bitmanipulation 
ersetzt werden: 


yMitte+y); 
yMitte+x); 
yMitte-x); 
yMitte-y); 
yMitte-y); 
yMitte-x); 
yMitte+x); 
yMitte+y); 

y - rHoch2 >= 0 THEN DEC(y) END 


(+ Bereichsüberprüfung wieder einschalten *) 
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x DIV 8 -v shr(x, 3) 
x MOD 8 -> and(x, 7) 

Wir überlassen dies dem Leser als Übung. Man kann natürlich noch einen Schritt weitergehen 
und die gesamte Routine Plot in Assembler schreiben; das bringt noch eine kleine Ge¬ 
schwindigkeitssteigerung, da die Prozeduraufrufe (für shr, and) dann wegfallen. Vielleicht 
packt Sie sogar der Ehrgeiz zur Entwicklung einer eigenen Routine zum schnellen Zeichnen 
von Linien mit Plot. Dies funktioniert ähnlich elegant wie beim Kreisalgorithmus. Man be¬ 
trachtet wieder die möglichen Nachbarpunkte eines Linienpunkts; das Kriterium für die rich¬ 
tige Auswahl liefert die Steigung. 


3.4 Kritisches zur Nutzung von Assembler 
in Modula-Programmen 

Diese Beispiele mögen als Anregung reichen. Vielleicht haben Sie ja Assembler-»Altbestände« 

in ihrer Software-Sammlung, und können diese nun auch unter Modula verwenden. Wir 

schließen das Kapitel noch mit einem erhobenen Zeigefinger und knüpfen damit an die ein¬ 
gangs dokumentierte Skepsis an: 

1. Einbindung von Assemblerroutinen in Modula-Prozeduren ist prinzipiell nicht nötig, da 
die flexiblen Jokertypen BYTE, WORD, L0NGW0RD, sowie ADDRESS für systemnahe Kon¬ 
struktionen zur Verfügung stehen. 

2. Für den Aufruf von Betriebssystem-Funktionen gibt es in den meisten Modula-Systemen 
sprachgerechte Module, die eine Schnittstelle zu diesen Funktionen bereitstellen. Ins¬ 
besondere zum Laden und Lesen einzelner Register verfügen viele Modula-Systeme über 
Prozeduren im Modul System. 

3. Assemblerroutinen sind nicht portabel auf andere Rechnertypen. Man sollte sie deshalb 
nur in gesonderten Modulen (»niedrigen Modulen«) benutzen, welche bei Bedarf ausge¬ 
tauscht werden können. Außerdem empfiehlt es sich, zusätzlich eine Modula-Lösung für 
diese Routinen bereitzuhalten. 

4. Die Erstellung von Assemblerroutinen ist sehr zeitaufwendig. Der erzielte Zeitgewinn 
beim Programmablauf (von oft nur ein paar Millisekunden) steht in keinem Verhältnis zu 
dem zusätzlichen Entwicklungsaufwand. 

5. Assemblerroutinen sind schlechter wartbar als Hochsprache. Fehler werden schneller ge¬ 
macht und sind schwer zu erkennen. 

Gerade der letzte Punkt hat es in sich: 
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Fehlerhafte Zuweisungen werden weder vom Compiler erkannt noch vom Laufzeitsystem ab¬ 
gefangen. Ein MOVE an die falsche Stelle, eine fehlerhafte Adressierungsart, ein Sprung ins 
»ungewisse« oder ein nicht richtig abgeglichener Stack führen im besten Fall »nur« zu einem 
Systemabsturz. Läuft das System dennoch weiter, wird der Fehler eventuell gar nicht erkannt. 
Inzwischen kann aber die RAM-Disk »zerschossen« worden sein. Noch schlimmer ist, wenn 
zum Beispiel ein falsches Byte im Harddisk-Buffer landet. Das kann zum kompletten Verlust 
der Daten führen! 

Der einzige Grund, der für den Einsatz von Assemblerroutinen spricht, ist ihre Effizienz: 

1. Geschickt programmierte Assemblerroutinen liefern schnelleren Code als die Überset¬ 
zung des Modula-Compilers. 

2. Der Code ist oft kürzer. Schauen sie doch einmal mit einem Monitorprogramm nach, was 
der Compiler aus der Prozedur Aus Tauschi vom Anfang des Kapitels macht! 

Der zweite Vorteil spielt kaum eine Rolle, da die Laufzeitfunktionen ohnehin den meisten 
Platz verschwenden. Der erste Vorteil wird nur dann merklich, wenn eine Routine sehr oft ge¬ 
braucht wird, zum Beispiel bei einem Aufruf in einer Schleife. 

Mit den immer besser werdenden Compilern, die den Code eigenständig optimieren, verliert 
also auch der Vorteil der höheren Effizienz immer mehr an Gewicht. Man sollte bedenken, daß 
auch schon Betriebssysteme in Modula geschrieben worden sind. 
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Sobald Sie Ihren Atari einschalten, freuen Sie sich über eine grafische Benutzeroberfläche mit 
Ikonen, Fenstern und Menüs. Dieser Bildschirmzauber ermöglicht der sogenannte GEM 
(Grafics Environment Manager, zu deutsch etwa »Verwalter für die grafische Umgebung«). 
Sicherlich haben Sie schon längst die bequeme Handhabung beispielsweise einer »File-Selec- 
tor-Box« zum Anwählen von Dateien schätzen gelernt und wollen nun auch den eigenen Pro¬ 
grammen mit diesen Segnungen einen professionellen Charakter geben. 

Kein Problem unter Modula! Alle Compiler enthalten ein Paket von GEM-Routinen, die Sie 
nur in Ihre Programme importieren und aufrufen brauchen. Im Gegensatz zum geplagten 
Assembler- oder »C«Programmierer findet man je nach Modula-Compiler sogar einige über¬ 
geordnete Module vor, die Bereiche dieser Routinen zusammenfassen und die Benutzung von 
GEM vereinfachen. Beispiele hierzu wären Textwindows unter Megamax und SPC- Modula, 
oder noch leistungsstärker SSWiS (Small Systems Windowing Standard) ebenfalls unter 
SPC-Modula. 

Im einzelnen dürften folgende Themen interessieren: 

• Textfenster 

• Alertboxen 

• File-Selector-Boxen 

• Line-A-Grafik 

• VDI-Grafik 

• Pull-down-Menüs 

• Dialogboxen 

• SSWiS-Programmierung 

Bevor wir jedoch auf die einzelnen Themen zu sprechen kommen, erhalten Sie im ersten 
Abschnitt einen Überblick über das Betriebssystem des Atari. 


4.1 Einführung in die Hierarchie des GEM 

Möglicherweise sind Sie von der Vielzahl der zu ihrem Modula-System mitgelieferten 
GEM-Module erschlagen. Dieser Abschnitt wird Klarheit verschaffen. 

Zunächst einmal gibt es beim Atari ein ganz normales Betriebssystem, das sogenannte TOS 
(»The Operating System«, im Volksmund auch »Tramil Operating System«). Wie bei den Be¬ 
triebssystemen CP/M und MS-DOS handelt es sich hierbei um ein Kommando-orientiertes 
System. Es hat die Aufgabe, zwischen der Benutzeroberfläche und der Hardware zu vermit¬ 
teln. Es besteht aus dem Trio 
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• BIOS (Basic Input Output System) 

• XBIOS (EXtendet BIOS) 

• GEMDOS (GEM Disk Operating System) 

Das BIOS bildet die unterste Ebene der Ein-/Ausgabe. Es überträgt zum Beispiel einzelne Zei¬ 
chen zwischen Rechner und der Peripherie. Letzteres sind vor allem Bildschirm und Tastatur; 
auch Drucker, RS232- und MIDI-Schnittstelle gehören dazu. 

Das XBIOS ist eine Ansammlung unterschiedlichster Routinen, die das BIOS Atari-spezifisch 
erweitert: dazu zählt die Kommunikation mit der Maus, dem Bildschirm und den Laufwerken 
sowie die Bedienung von MIDI- und RS232-Schnittstelle, Tastatur, Timer und vieles andere 
mehr. 

BIOS und XBIOS bilden zusammen den hardware-abhängigen Teil des Betriebssystems. Im 
Gegensatz dazu stellt GEMDOS den hardware-unabhängigen Teil dar. Zu seinen Aufgaben 
gehört die Speicher- und Diskettenverwaltung, wobei soviel wie möglich an BIOS und XBIOS 
delegiert wird. Hier kann der Eindruck entstehen, daß einige Funktionen doppelt Vorkom¬ 
men, also einige Funktionen, die man im BIOS oder im XBIOS sieht, im GEMDOS wieder 
unter ähnlichem Namen auftauchen. Z. B. schreibt die GEMDOS-Routine Coconout(ch) 
das Zeichen ch auf die »Standard-Ausgabeeinheit« (normalerweise der Bildschirm); der Auf¬ 
ruf der BIOS-Routine Bconout(device, ch) bewirkt dasselbe, wenn man als device 
(= Gerät) den Bildschirm angibt. 

Tatsächlich handelt es sich aber um ein Zusammenfassen und Übergeben in eine niedrigere 
Ebene, also das, was man auch im Berufsleben unter Management versteht. 

Die GEMDOS-Routinen entsprechen weitgehend denen von MS-DOS und stimmen sogar in 
den Funktionsnummern überein. 

Insgesamt haben wir also mit TOS ein komplettes, konventionelles Betriebssystem. Davon 
merkt man aber eben nur wenig, denn der Knüller beim Atari ist nun, daß diesem Betriebs¬ 
system ein weiterer »Manager« übergeordnet ist, nämlich GEM. Hiermit ist es möglich, dem 
Computer seine Wünsche nicht wie in einer trockenen Kommandosprache mitzuteilen, son¬ 
dern in einer benutzerangepaßten »Welt« von Aktenordnern, Fenstern und Papierkorb, die 
quasi mit dem Zeigefinger (der Maus) bedient werden können. GEM delegiert wiederum die 
gestellten Aufgaben weitgehend an das TOS. Darüber hinaus gibt es einige Dienste, die TOS 
nicht erledigen kann; dazu muß GEM direkt auf die Hardware zugreifen. 

Im Unterschied etwa zu IBM-Computern, wo man auch GEM zusätzlich laden kann (was 
zirka 300 Kbyte des ohnehin knappen Speicherplatzes von 640 Kbyte belegt), ist GEM beim 
Atari fest im ROM eingebaut und belegt zusammen mit dem TOS 192 Kbyte. Insgesamt erhält 
man folgendes Bild: 
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GEM 



Hardware des ATARI ST 


Bild 4.1: Hierarchie des Betriebssystems des Atari-ST 

Die Zeichnung macht gleichzeitig die Größenverhältnisse der Betriebssystem-Komponenten 
deutlich. 

GEM gliedert sich zunächst in einen hardware-abhängigen Teil mit 16 sogenannten 
Line-A-Grafik-Routinen, über die alle Grafik- und Textausgaben des GEM laufen. Diese 
Routinen arbeiten sehr schnell und sind beispielsweise für die Programmierung von Spielen 
sinnvoll. Man kann sie natürlich unter Modula nutzen (mehr dazu in Abschnitt 4.5), sie sind 
aber recht »primitiv«. 

Der übergeordnete rechnerunabhängige Teil von GEM unterteilt sich ins AES Application 
Environment Service) mit 48 und VDI (Virtual Device Interface) mit 79 Routinen. 

Das VDI stellt eine geräteunabhängige Grafik-Schnittstelle dar und beinhaltet alle Grafik¬ 
funktionen, wie Linien und Kreisbögen zeichnen oder Flächen füllen oder Text ausgeben. 
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Das AES übernimmt die Verwaltung einer Anwendung, die in einer grafisch arbeitenden Um¬ 
gebung abläuft. Die Palette der AES-Routinen umfaßt umfangreiche Abfragemöglichkeiten 
für Maus und Tastatur. Auch Fensterverwaltung, die Pull-down-Menüs, Alert- und Dialog¬ 
boxen fallen hierunter. 

Es stellt sich die Frage, wozu der Modula-Programmierer Betriebssystemaufrufe anwenden 
bzw. warum er den Umgang mit ihnen kennen sollte. 

1. Für TOS-Aufrufe sehen wir nur drei Anwendungsbereiche: 

• Lesen von Sondertasten der Tastatur (darauf wurde im Abschnitt 1.7.3 eingegangen). 

• Auslesen des Disketten-lnhaltsverzeichnisses. Wir gehen nicht darauf ein, da einzelne 
Systeme hierfür fertige Schnittstellen liefern. 

• Erzeugung von Tönen über den eingebauten Soundchip. Hierzu bringen wir im An¬ 
schluß einen kleinen Modul. 

2. Die Benutzung der Line-A-Routinen wird von den meisten Modula-Systemen unterstützt. 
Wir gehen darauf im Abschnitt 4.5 ein. 

3. Am wichtigsten sind die VD1- und AES-Routinen. Hierzu folgen zahlreiche Beispiele in 
den Abschnitten 4.6 bis 4.8. 

Vor dem Überblick über die VDI- und AES-Routinen gehen wir noch auf die Programmie¬ 
rung des Soundchip YM-2149 als reine TOS-Anwendung ein. 


4.1.1 Eine TOS-Anwendung: 

Programmierung des Soundchip YM-2149 

Zur Erzeugung von Tönen, Klängen und Geräuschen bietet der Soundchip 16 Register, R 0 bis 
r 15 , deren Bedeutung im folgenden beschrieben wird. Mit der Prozedur XBIOS. GlWrite 
läßt sich unter Megamax-Modula Bytes in diese Register schreiben. Der Modul XBIOS liegt 
bei diesem System in einem speziellen Ordner TOS. Sollte Ihr Modula-System GlWrite nicht 
bereitstellen, so finden Sie vermutlich XBIOS. GlAccess. Diese Prozedur erlaubt das Be¬ 
schreiben und Lesen der Soundchip-Register. Beim Schreiben ist der gewünschte Byte-Wert 
um 080H = I28 dezimal zu erhöhen. 

Zur Tonerzeugung gibt es drei Tongeneratoren (Kanal A, B und C), die gleichzeitig erklingen 
können! Damit kann man mehrstimmig spielen. Wie veranlaßt man nun einen Tongenerator 
dazu, einen bestimmten Ton von sich zu geben? 
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1. Initialisierung: Lautstärke, Tonhöhe usw. einstellen (dazu müssen bestimmte Register ge¬ 
laden werden). 

2. Einen (oder mehrere) Kanäle einschalten. Der Ton erklingt solange, bis der Kanal wieder 
abschaltet. Der Rechner kann derweilen etwas anderes tun, da die 68000-CPU nicht mehr 
beansprucht wird. Über die CPU werden nur die Register gesetzt, die Tonerzeugung 
macht der Soundchip eigenständig. 

3. Abschalten der eingeschalteten Kanäle, der Ton soll ja nicht ewig klingen. 

Die Register des Soundgenerators 

Register R 0 , Ri: 

Das Byte für R 0 sowie die unteren 4 Bit für R x bestimmen die Periodendauer des Kanals A. 
Für eine bestimmte Frequenz (in Hertz) errechnet sich die Periodendauer wie folgt: 
Periodendauer = 125000 / Frequenz 

Beispiele: Der höchste Periodenwert ist 4095 (alle 12 Bit auf »1«); ihm entspricht die Fre¬ 
quenz 30.53 Hz. Dem Periodenwert 8 entspricht die Frequenz 15625 Hz. Der Kammerton 
a’ (440 Hz) benötigt die Periodendauer 284. 

Register R 2 , R 3 : 

Wie R 0 ,R X , jedoch für Kanal B. 

Register R 4 , R 5 : 

Wie R 0 ,R X , jedoch für Kanal C. 

Register R 6 : 

Die unteren fünf Bits legen die Periodendauer des Rauschgenerators fest. 

Register R 7 : 

Mit diesem Register schaltet man die einzelnen Kanäle ein bzw. aus. Der Rauschgenerator 
kann zu jedem Kanal zugeschaltet werden. Die Bedeutung der einzelnen Bits in R 7 : 

Bit Nr. Bedeutung 

0: 0 = Kanal A ein, 1 = Kanal A aus 

1: 0 = Kanal B ein, 1 = Kanal B aus 

2: 0 = Kanal C ein, 1 = Kanal C aus 

3: 0 = Rauschen zu Kanal A zuschalten, 1 = abschalten 

4: 0 = Rauschen zu Kanal B zuschalten, 1 = abschalten 

5: 0 = Rauschen zu Kanal C zuschalten, 1 = abschalten 

6: 0 = Port A als Eingang, 1 = als Ausgang 

7: 0 = Port B als Eingang, 1 = als Ausgang 

Bit 6 und 7 spielen für den Tongenerator keine Rolle. 
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Register R 8 , R 9 , R 10 : 

Die unteren 4 Bit bestimmen die Lautstärke für Kanal A, B bzw. C. Ist Bit 4 (das fünfte) 
gesetzt, wird die Lautstärke durch einen Hüllkurvengenerator gesteuert. 

Register R 1X , R 12 : 

Die Periodendauer T H der Hüllkurve wird hiermit festgesetzt (vgl. Abb). R n enthält das 
untere, R 12 das obere Byte. 

Register R 13 : 

Die unteren 4 Bits definieren die Kurvenform der Hüllkurve. Die Bits heißen: 

Bit Nr. Name 
0: Hold 

1: Alternate 

2: Attack 

3: Continue 

Die Auswirkungen entnimmt man der Grafik auf der folgenden Seite. 

Register R 14 , R 15 : 

Spielen für uns keine Rolle. 

Der folgende kleine Modul schöpft bei weitem nicht alle Möglichkeiten der Sound-Program¬ 
mierung aus. Auf die Modula-gerechte Umsetzung mittels des Datentyps Bitset wurde ver¬ 
zichtet. Ebenso auf die Benutzung des Rauschgenerators. Hier ist für den Programmierer ein 
weites Experimentierfeld gegeben. Wer sich tiefer in die Materie einarbeiten will, dem sei das 
Buch [M] empfohlen. 
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BESCHREIBUNG 


KURVENFORM REGISTER 7 


Abwärtsrampe 



2 1 0 Wert 

0 0/1 0/1 0-3 


Aufwärtsrampe, Abwärtssprung, 
Halten auf Null 


umgekehrter Sägezahn 


/I_ 


1 0/1 0/1 4-7 


0 0 0 8 


Abwärtsrampe 


0 0 1 9 


umgekehrtes Dreieck 

Abwärtsrampe, Aufwärtssprung, 
Halten bei 15 

Sägezahn 

Aufwärtsrampe, Halten bei 15 


N 

/IW 

/ 


0 1 0 10 


0 11 11 


1 0 0 12 


10 1 13 


Dreieck 



1 1 0 14 


Aufwärtsrampe, Abwärtssprung, 
Halten bei Null 


Continue 

Attack 

Alternate 

Hold 
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Bild 4.2: Die Hüllkurvenformen 

DEFINITION MODULE Sound; 

PROCEDURE Einsteilen(Lautstaerke: CARDINAL); 

(* 

* Liefert Voreinstellung für den Soundchip YM-2149. 

* Die Hüllkurven-Periode wird auf einen festen Wert gesetzt 
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* und die Lautstärke (0..15) eingestellt. 

* Bei Lautstärke = 16 wird der Hüllkurven-Generator benutzt. 

*) 

PROCEDURE Ton(Periode, Dauer: CARDINAL); 

(* 

* Dient zur Erzeugung eines Tons mit dem Soundchip YM-2149. 

* Frequenz (in Herz) = 125000 / Periode; 

* z.B. Kammerton a’ (440 Hz): Periode = 284. 

* 1 <= Dauer < = 255; 

*) 

PROCEDURE Aufhoeren; 

(* 

* Zum Abschalten des Soundgenerators. 

* *Aufhoeren’ ist stets am Ende einer Sequenz von Tönen aufzurufen; 

* anderfalls bleibt der letzte Ton bestehen. 

*) 

PROCEDURE Wecker; 

(* 

* Liefert eine Folge von Tönen, um den Programmbenutzer auf 

* etwas hinzuweisen, z.B Beendigung einer Zeichnung. 

*) 

END Sound. 


IMPLEMENTATION MODULE Sound; 

FROM XBIOS IMPORT GIWrite; 

FROM Stoppuhr IMPORT Warten; 

PROCEDURE Einsteilen(Lautstaerke: CARDINAL); 
CONST HuellkurvenPeriode = 10000; 

BEGIN 

GIWrite(8, Lautstaerke); 

GIWrite(ll, HuellkurvenPeriode MOD 256); 
GIWrite(12, HuellkurvenPeriode DIV 256); 
END Einstellen; 

PROCEDURE Ton(Periode, Dauer : CARDINAL); 
BEGIN 

GIWrite(0, Periode MOD 256); (* RegO 

GIWrite(l,Periode DIV 256); (* Regl 


(* Reg8 = Lautstärke 0..15 *) 


= Periodenwert Lowbyte Kanal A *) 
= Periodenwert Highbyte Kan. A *) 
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GIWrite(7,OPEH); 

GIWrite(13,9); 

Warten(LONG(Dauer)); 
END Ton; 


(* Reg7 = Schalter,PE = nur Kanal A an *) 
(* Frequenz(in Hertz) = 125000/Periode *) 
(* Regl3 = Hüllkurve: fallende Attack *) 
(* etwa wie Klavier oder Gitarre *) 
(* Warten, bis der Ton abgearbeitet ist *) 


PROCEDÜRE Aufhoeren; 

BEGIN 

GIWrite(7,OEPH); (* Alle Kanäle ausschalten *) 

END Aufhoeren; 

PROCEDÜRE Wecker; 

CONST 

cl = 478; el = 369; gl = 319; c2 = 239; 

BEGIN 

Einstellen(16); (* volle Lautstärke *) 

Ton(cl, 25); Ton(el,25); Ton(gl,25); 

Ton(c2, 50); Ton(c2,25); Ton(c2,75); 

Aufhoeren (* Soundchip abschalten *) 

END Wecker; 

END Sound. 


Probieren Sie den Modul mit dem folgenden kleinen Programm aus: 


MODULE SoundDemo; 

PROM Sound IMPORT Einstellen, Ton, Aufhoeren, Wecker; 
PROM InOut IMPORT WriteString, WriteLn, ReadCard; 

PROM Stoppuhr IMPORT Warten; 

CONST 

cl = 478; dl = 426; el = 369; fl = 358; 


gl = 319; al = 284; hl = 253; c2 = 239; 

VAR periode, dauer, lautstaerke : CARDINAL; 

BEGIN 

Wecker; 

Warten(lOO); 

Einstellen(15); Ton(4091,255); Aufhoeren; 
Warten(100); 


*0.5 Sec. warten *) 


(* 0.5 Sec. warten 


) 
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Einstellen(16); (* Lautstärke vom Hüllkurven-Generator regeln lassen -*) 


Ton(cl,40); Ton(dl,20); Ton(el,20); 
Ton(gl,20); Ton(al,20); Ton(hl,20); 
Aufhoeren; 

Einstellen(lö); 

LOOP 

WriteString("Periode (0 = ENDE): 
IP periode = 0 THEN EXIT END; 
WriteString("Dauer in 5ms (<256): 
Ton(periode, dauer); 

Aufhoeren 

END; 


Ton (fl, 20); 

Ton(c2,80); 

(* volle Lautstärke *) 
'); ReadCard(periode); 

"); ReadCard(dauer); 


Aufhoeren; 
END SoundDemo. 


Nach diesem Beispiel für einen Aufruf einer TOS-Routine wenden wir uns nun den GEM- 
Routinen zu. 


4.1.2 Überblick über die AES- und VDI-Routinen 

Die AES- und VDI- Routinen werden von den verschiedenen Modula-Systemen in inhaltlich 
zusammengehörigen Modulen zusammengefaßt. Dies soll am Beispiel von Megamax-Mo- 
dula gezeigt werden. Die Nutzung wird in den Programmen der nachfolgenden Abschnitte 
klargemacht. 

Es würde den Rahmen dieses Buches sprengen, alle Prozeduren aus GEM mit der Vielzahl 
ihrer Parameter hier aufzuzählen. Wir müssen hierzu auf die einschlägige Literatur zum GEM 
verweisen. 

Vielleicht kennen Sie aus C-Programmen die Original-Bezeichnungen der GEM-Routinen. 
Sie haben oft etwas chaotische Namen wie »v_openvwk«, was davon herrührt, daß der erste 
C-Compiler nur 8 signifikante Zeichen in einem Bezeichner unterscheidet. Die meisten Mo- 
dula-Compiler verwenden deshalb eigene Namensgebungen. Hänisch-Modula übernimmt 
aber die Original-Bezeichner, was dem GEM-erfahrenen Programmierer sicherlich gefallen 
wird. Hier heißt die Prozedur v. openvwk, da der VDI-Modul geschickterweise »v« heißt. 
Außerdem stimmen die Parameterlisten überein. Auch das MSM2-System hält sich stark an 
den C-Standard, der im Übrigen von der gesamten Literatur zum GEM üblich ist. 

Bei anderen Modula-Compilern stimmen leider Gliederung, Bezeichnung und Parameterli¬ 
sten der Routinen nicht überein, sie sind aber einander ähnlich. Aus Platzgründen müssen wir 
für die Abweichung auf die entsprechenden Handbücher verweisen. 
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Unter Megamax stehen die folgenden Module zur Verfügung: 

VDIAttributes Attribut-Bibliothek 

Voreinstellungen der Art der Ausgabeoperationen für VDlOutputs 

VDlControls Kontrollprozeduren 

Löschen des Arbeitsbereiches, Laden von Fonts, Clipping 

VDIEscapes Escape-Bibliothek 

Spezielle Atari-Spezifische Routinen (größtenteils undokumentiert): Hardcopy, Fonts 
etc. 

VDI Input s Eingabe-Bibliothek 

Eingabe über Tastatur und Maus (Achtung! Einige Routinen funktionieren nicht) 

VDIInquires Nachfrageprozeduren 

Erfragen der Parameter, die mit VDI-Attributes gesetzt worden sind 

VDlOutputs Ausgabeprozeduren 

General Drawing Primitives (GDP, »Grund-Zeichenfunktionen«), Linien, Flächenfüllen 
usw. (Wichtig!) 

VDlRasters Raster-Bibliothek 

Kopieren beliebiger Rechteckbereiche, Bestimmung der Farbe eines beliebigen Pixels 

AESEvent s Ereignis-Bibliothek 

Warten auf Tastatur-, Maus-, oder Timer-Ereignisse 

AESForms Formular-Bibliothek 

Ausführungen von Dialogen (Alertbox, Dialogbox) 

AESGrafics Grafik-Bibliothek 

Verkleinern, Vergrößern, Verschieben von Rahmen auf dem Bildschirm 

AESMenus Menü-Bibliothek 

Bearbeitung von Pull-down-Menüs 

AESMisc Verschiedens 

Unter anderem File-Selector-Box 

AESOb j e c t s Objekt-Bibliothek 

Manipulation von sogenannten Objektbäumen (Gruppierungen von Grafik-Objekten) 

AESRe s ource s Resourcebehandlungs-Bibliothek 

Bearbeiten von Resourcen, die mit dem Resource-Construction-Set erstellt werden, 
(z. B. Menüs, Dialogboxen) 
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AESWindows Fenster-Bibliothek 

Fenster-Management 

Außerdem gibt es bei Megamax noch einige Module, die zur Arbeit mit GEM gehören, wie 
GEMEnv, GEMGlobals, GrafBase, LineA, ObjHandler, EventHandler und TextWindows. 

Da die Anwendung von GEM-Aufrufen nicht ganz einfach ist, stellt SPC für fensterorien¬ 
tierte Anwendungen das Modul SSWiS zur Verfügung. Man verspricht sich von SSWiS eine 
Verbreitung auf andere Systeme (Unix und OS/2-Rechner). Damit wären Modula-Pro- 
gramme, die nur SSWiS für die fensterorientierte Ein-/Ausgabe nutzen, auf solche Rechner 
portierbar. Außerdem sind die SSWiS-Routinen deutlich einfacher und »ohne lange Vorrede« 
zu benutzen. 

Wichtig ist noch, folgendes zu wissen: Bevor ein Programm GEM-Routinen benutzt, hat es 
sich höflich beim GEM anzumelden und nach getaner Tat sich wieder abzumelden. Wie man 
dies macht, zeigen wir in Abschnitt 4.6. Weil hiermit immer wiederkehrende Anweisungen zu 
erledigen sind, bringen wir hierfür einen externen Modul. 

Bei der Benutzung von Line-A-Routinen ist ein Anmelden allerdings nicht erforderlich. 

Sicherlich bleiben nach dem erstem Lesen dieses Abschnittes noch etliche Fragen. Diese dürf¬ 
ten sich in den nachfolgenden Beispielen klären. Nun endlich hinein ins GEM! 


4.2 Benutzung von Textfenstern 

Ein Modul »TextWindows« schlägt bereits N. Wirth in [Wl] als Standardmodul vor. 
Nahezu alle Modula-Systeme für den Atari bieten eine Implementation. Beim SPC-System 
stützt sie sich voll auf die SSWiS-Prozeduren. 

Eine ähnlich gelungene Implementierung ist die von Megamax-Modula, dem die folgenden 
Programmbeispiele zugrunde liegen. Die wesentlichen Ein-/Ausgaberoutinen heißen so, wie 
sie vom Modul Terminal bekannt sind (Beispiele: Goto XY, Read, Write, ReadString, 
Wr iteSt ring). Man kann also Programme, die man für die Ein-/Ausgabe auf dem TOS-Bild¬ 
schirm entwickelt hat, sofort portieren und somit schnell einen einfachen Fensterzauber ent¬ 
fachen. TextWindows benutzt die AES-Fensterverwaltungs-Routinen, ohne daß der Pro¬ 
grammierer die AES-Module selbst aufrufen muß. Man befindet sich also noch eine Stufe über 
dem GEM. 

Bei jeder Eingabe kann der Benutzer eines mit TextWindows geschriebenen Programms die 
Fenster mit der Maus manipulieren (Verschieben, Größe verändern, mit den Fensterschie¬ 
bern Scrollen usw.). Lediglich das Schließen des Fensters durch Anklicken des Schließsymbols 
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muß noch durch das Programm unterstützt werden; dadurch wird sichergestellt, daß das Pro¬ 
gramm das Schließen zur Kenntnis genommen hat und dort also nichts mehr ausgeben kann. 

Das nachfolgende kleine Demonstrations-Programm öffnet zwei Fenster. In jedem Fenster 
kann man einen String eingeben, der in dem anderen Fenster ausgegeben wird. Spielen Sie ein 
wenig mit der Maus während des Programmlaufes! 


MODULE TextWindowDemo; 

PROM TextWindows IMPORT Window, Open, Close, Hide, WasClosed, 

WindowQuality, WQualitySet, ShowMode, ForceMode, 
GotoXY, ReadString, WriteString, KeyPressed; 

VAR Pensterl, Penster2 : Window; 

ok : BOOLEAN; 

sl,s2 : ARRAY[0..50] OP CHAR; 


BEGIN 

Open(Fensterl,80,25,WQualitySet{ movable. . titled} , noHideWdw,forceTop, 
”Mein erstes Fenster”,10,12,50,10, ok); 

0pen(Fenster2,80,25,WQualitySet( movable. . titled} , noHideWdw, forceTop, 
"Mein zweites Fenster”,35,2,40,20, ok); 

WriteString(Fensterl,"Spielen Sie mit der Maus an den Fenstern!” ); 
GotoXY(Fensterl,5,5); 

ReadString(Fensterl,sl); 

GotoXY(Fenster2,3,5); 

WriteString(Fenster2,sl); (* sl wird in das 2. Fenster übertragen *) 

GotoXY(Fenster2,3,10); 

ReadString(Fenster2,s2); 

GotoXY(Fensterl,5,8); 

WriteString(Fensterl,s2); (* s2 wird in das 1. Fenster übertragen *) 

REPEAT 


IF WasClosed(Fensterl) THEN Hide(Fensterl) END; (* Closer bedient? *) 
IF WasClosed(Fenster2) THEN Hide(Fenster2) END; (* ggfs, schließen *) 
UNTIL KeyPressed(); 

Close(Fensterl); 

Close(Fenster2); 

END TextWindowDemo. 
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TEXTMIND.PRG 


Mein zweites Fenster 


flTfiRI-ST und Modula-2 


IMein erstes Fenster! 


ein starkes Tean! 


Bild 4.3: Zwei Textfenster 

Wenn man keine Grafik benötigt und dennoch mit mehreren Fenstern arbeiten will, empfiehlt 
sich die Verwendung von TextWindows. Die Handhabung ist einfach, das An- und Abmelden 
beim GEM wird automatisch erledigt. Leider stehen nicht alle komfortablen Eingaberouti¬ 
nen, die man vom Modul inOut kennt, zur Verfügung (es fehlt z.B. ReadReal). Will man 
über mit TextWindows erzeugten Fenstern REAL-Zahlen einiesen, so muß man sie erst als 
String abholen (mit ReadString) und dann in REAL-Zahlen umwandeln (dafür gibt es 
Routinen in StrConvert. Da unsere eigenen Leseroutinen aus Abschnitt (1.7.3) auf InOut 
aufbauen, lassen Sie sich sofort für TextWindows nutzen, wenn man in der Importliste InOut 
durch TextWindows ersetzt. 

Eingabesteuerung mit der Maus 

Ein besonderer Leckerbissen ist die Benutzung der Maus innerhalb der Fenster. Die Prozedur 
DetectChar übergibt die dem Mauspfeil entsprechende Cursor-Spalte und -Zeile beim An¬ 
klicken wieder. Beim folgenden Demonstrations-Programm geht es um das Anklicken von 
Menüpunkten. Die Menüpunkte stehen in einem Window untereinander; das Programm 
braucht also nur festzustellen, in welcher Zeile »geklickt« wurde. 
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MODULE TextWindowMitMausDerao; 


PROM GrafBase IMPORT Point, Rectangle; 
PROM TextWindows IMPORT Window, Open, Close, 


WindowQuality, WQualitySet, ShowMode, PorceMode, 
GotoXY, Write, WriteString, KeyPressed, 
DetectChar, DetectMode, DetectResult; 


CONST 


ESC = 33C; 


VAR 


Penster 


Window; 

ARRAY[0..0] OP Window; 
DetectMode; 

Point; 


ziel 

modus 

punkt 


zeile, spalte,i : CARDINAL; 


rechteck 

ergebnis 

ok 


Rectangle; 

DetectResult; 

BOOLEAN; 

ARRAY[0. . 2 ] OP ARRAY[0..8] OP CHAR; 


s 


BEGIN 


Open(Penster,80,25,WQualitySet{titled}, noHideWdw, forceCursor, 

"Fenster mit Mausbedienung”, 10, 3, 60,15, ok); 
s[0]:=” Wahll ”; s[l]:=” Wahl2 ”; s[2]:=” Wahl3 ” ; 

POR i:=0 TO 2 DO 

GotoXY(Penster,10,i+ 5); 

WriteString(Penster,s[i]) 

END; 

ziel[0]:=Penster; 
modus:=requestPnt; 

REPEAT 

DetectChar(ziel,1,modus,punkt,Penster, spalte, zeile, rechteck, ergebnis) 
UNTIL (5 <= zeile) & (zeile <= 7); 

GotoXY(Penster,10,zeile); 

Write(Penster,ESC); Write(Penster, ”p”); (* VT-52 Steuerzeichen invers *) 
WriteString(Penster,s[zeile-5]); 

Write(Fenster,ESC); Write(Penster,”q”); (* VT-52 Steuerzeichen normal *) 

GotoXY(Penster,10,12); 

WriteString(Penster,”Sie wählten aus: ”); 
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WriteString(Fenster,s[zeile-5]); 
REPEAT UNTIL KeyPressed(); 
Close(Fenster); 

END TextWindowMitMausDemo. 


Die Programmierung von »Pull-down«-Menüs wird in Abschnitt 4.7 gezeigt; das Programm 
»Satellitenbahnen« zeigt eine weitere Anwendung von TextWindows. 

4.3 Benutzung von Alertboxen 

Im vorigen Abschnitt haben wir einen zu GEM übergeordneten Modul benutzt; um das ei¬ 
gentliche Gerangel mit den GEM-Routinen konnten wir uns dabei noch einmal drücken. Nun 
wollen wir als erstes echtes GEM-Beispiel die einfachste Anwendung vorstellen: die Alert¬ 
boxen (»Alarmkästen«), die man überall in Programmen antrifft, wenn einmal wieder etwas 
falsch gemacht worden ist. Alles nötige erledigt die Routine FormAlert aus AESForms. Sie 
enthält drei Parameter: 

1. Parameter: 

die Nummer des vorgewählten Knopfes, der auch mit <Return> zu bedienen ist. 

2. Parameter: 

ein String, der die Beschriftungen der Alertbox bestimmt. Er ist folgendermaßen aufge¬ 
baut: 

”[ikonennr] [Zeilel|Zeile2. . . ] [Knopfl|Knopf2|Knopf3] ” 

Wichtig: es sind nur 

• maximal 5 Zeilen 

• maximal 3 Knöpfe 
erlaubt. 

Die Ikonen-Nummer hat folgende Bedeutung: 

• 0: Kein Icon 

• 1: Ein Icon mit Ausrufezeichen 

• 2: Ein Icon mit Fragezeichen 

• 3: Ein Icon mit Stoppzeichen 

3. Parameter: 

Hier steht nach Beendigung der Routine, welchen Knopf der Benutzer angeklickt hat. 
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Dieses 

Modula-Buch 

ist 

große Klasse 


stinnt "I Iweiß nicht] I falsch 


Das kleine Programm bringt folgenden Bildschirm: 

flLERTBOX.PRG 


Bild 4.4: Eine Alert box 

Je nach Knopfdruck erhält man eine entsprechende Antwort. Alles andere geht aus dem Pro¬ 
grammtext hervor. Die GEM-An-/Abmeldung erledigen wir mit dem Modul Grafik, der in 
Abschnitt 4.6 vorgestellt wird. 

MODULE AlertBoxDemo; 

PROM AESPorms IMPORT PormAlert; 

PROM Grafik IMPORT anmelden, abmelden; 

VAR AntwortKnopf : CARDINAL; 

s : ARRAY [0..80] OP CHAR; 

BEGIN 

anmelden; 

s: =”[1] [Dieses|Modula-Buch|ist|große Klasse] [stiramt|weiß nicht|falsch]”; 

PormAlert(1,s,AntwortKnopf); 

CASE AntwortKnopf OP 

1 : s: =”[1][Gratuliere! |Sie haben|einen guten Geschmack][Ende]” t 

2 : s:-”[2][Wir empfehlen Ihnen, (noch etwas weiterzulesen][Ende]” | 

3 : s:=”[3][Sie habenjdas Buchjwohl nur|kurz durchgeblättert!] [Ende]” 
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END; 

FormAlert(1,s,AntwortKnopf); 
abmelden; 

END AlertBoxDemo. 

Das Programmbeispiel wurde mit Megamax-Modula entwickelt. Leider weichen die Imple¬ 
mentationen der GEM-Routinen anderer Modula-Compiler leicht voneinander ab. 

In SPC-Modula zum Beispiel wird der angeklickte Knopf nicht über einen VAR-Parameter 
zurückgegeben, sondern als Funktionswert: 

PROCEDURE Alert(Defaultknopf: INTEGER) 

VAR String: ARRAY OF CHAR): INTEGER; 

In TDI-Modula findet man eine identische Parameterliste, die Prozedur dafür heißt aber 
FormAlert. Den selben Namen hat sie beim MSM2-System. Hänisch-Modula verwendet den 
Standardbezeichner form, alert (der Modul heißt form). 

Wir hoffen, daß es dem Leser dieses Buches nicht schwerfällt, die Programmtexte auf seinen 
eigenen Compiler anzupassen. Der Einheitlichkeit halber halten wir uns im folgenden an die 
Megamax-Implementation. 


4.4 Benutzung einer File-Selector-Box 
und der Modul »Druck« 

Ebenso einfach wie der Umgang mit Alertboxen ist die Programmierung einer 
File-Selector-Box. Hierzu dient die Prozedur 

PROCEDURE SelectFile(VAR Pfad,Filename: ARRAY OF CHAR; 

VAR ok: BOOLEAN); 

aus AESMi sc. Bei SPC und TDI-Modula heißt die Prozedur FileSelectorlnputund stammt 
aus AESForms; bei TDI-Modula ist Pfad und Filename (etwas unhandlich) vom Typ ADDRESS 
und kein VAR-Parameter! Den Standard C-Bezeichner f sel_input verwendet das MSM2- 
System in ähnlicher Weise: hier hießt die Routine Fsellnput (der »_« (Unterstrich) ist in 
Modula nicht erlaubt). Bei Hänisch-Modula heißt sie fsel. input, der Modul heißt 
raffinierter Weise fsel. 
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Schimpfen Sie also nicht, wenn die Programme auf der mitgelieferten Diskette mit Ihrem 
System nicht auf Anhieb zu kompilieren sind. 

Mit diesem Wissen und dem Handbuch ihres Systems dürfte es Ihnen jedoch jetzt keine 
Schwierigkeiten mehr bereiten, die Prozeduren entsprechend anzupassen. 

Die Prozedur öffnet eine File-Selector-Box entsprechend dem vorgegebenen Pfad (Laufwerk, 
Ordner). In ok steht nach dem Aufruf, wie der Benutzer die Box verlassen hat: 

FALSE: »Abbruch«-Knopf gedrückt 
TRUE : »OK«-Knopf gedrückt 

In letzterem Fall bestimmen Pfad und Filename das angewählte File. 

MODULE FileSelectorBoxTest; 

FROM AESMisc IMPORT SelectFile; 

FROM Grafik IMPORT anmelden, abmelden; 

FROM InOut IMPORT GotoXY, WriteString, KeyPressed; 

VAR pfad, name : ARRAY [0..80] OF CHAR; 
ok : BOOLEAN; 

BEGIN 

anmelden; 

pfad: = ”A: *. *”; name: 

SelectFile(pfad,name,ok); 

GotoXY(l, 23); 

WriteString(”Der Pfad heißt: ”); 

WriteString(pfad); 

IF ok THEN 

WriteString(”, das ausgewählte File heißt: ”); 

WriteString(name) 

ELSE WriteString(”, es wurde kein File ausgewählt.”) END; 

REPEAT UNTIL KeyPressed(); 
abmelden; 

END FileSelectorBoxTest. 


Druckprogramm für Textfiles 

Wir nutzen die Dienstleistung der File-Selector-Box für ein kleines Druckprogramm. Damit 
Sie gleich Ihre zahlreichen Modula-Textfiles (sowie andere ASCII-Files) ordentlich forma¬ 
tiert mit Kopfzeile und Seitennumerierung ausdrucken können, liegt das Programm auf der 
beigefügten Diskette auch in kompilierter Form als ».PRG«-File vor. 



Benutzung einer File-Selector-Box und der Modul »Druck« 


329 


Das Programm nimmt über die File-Selector-Box File-Namen entgegen und hängt die Namen 
der auszudruckenden Files an eine Schlange. Nach Beendigung der Auswahl (wenn der Be¬ 
nutzer »Abbruch« angeklickt hat) werden alle Files nacheinander ausgedruckt und Sie kön¬ 
nen sich eine Pause gönnen. Das Programm ist während des Drückens mit der <ESC>-Taste 
abbrechbar. Der Abbruch erfolgt unmittelbar, falls kein Druckerspooler oder sonstiger Zwi¬ 
schenspeicher im Drucker aktiv ist. 


MODULE Druck; 




FROM AESForms 

IMPORT 

FormAlert; 


FROM AESMisc 

IMPORT 

SelectFile; 


FROM Strings 

IMPORT 

String, Length, Delete, 

Concat, Assign, Copy, Append; 

FROM StrConv 

IMPORT 

CardToStr; 


FROM Files 

IMPORT 

Create, Open, Close, 




EOF, State, ResetState, 

File, Access, ReplaceMode; 

FROM Text 

IMPORT 

EOL, Read, Write, WriteString, WriteLn; 

FROM Grafik 

IMPORT 

anraelden, abmelden; 


FROM GEMDOS 

IMPORT 

PrnOS; 


IMPORT InOut; 




IMPORT Schlange; 



CONST 





ESC 

= 33C; 




FF 

= 14C; 

(* Druckersteuerzeichen 

für Seitenvorschub (Form Feed) 

*) 

Fett 

= 16C; 

(* Druckersteuerzeichen 

für Fettdruck, ggfs, abändern 

*) 

ZpS 

<£> 

»1 

(* Anzahl der Zeilen pro 

Seite - 1 beim Ausdruck 

*) 

StandardPfad - 

”A: \MODULA\*. 

(* Standardsuchpfad 

*) 


TYPE 

MeldungsTyp = (anleitung, prnWeg, fileWeg, pause); 

VAR 

prn : Eile; 

schlänge : Schlange.EIEO; 
weiter : BOOLEAN; 

PROCEDURE Meldung(art : MeldungsTyp); 

VAR s : String; 

knöpf : CARDINAL; 
ok : BOOLEAN; 

BEGIN 

CASE art OF 
anleitung : 
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s := ”[1] [Drucker an|Papier ok?|Files wählen|Druckabbruch mit ESC] ” J 
prnWeg: 

s := ”[3] [Drucker|arbeitet nicht !|Bitte prüfen! (Online? Ready?]” i 
fileWeg: 

s := ”[3][Das File|ist weg! jBittejDiskette prüfen.]” | 
pause: 

s := ”[2][Der Ausdruck|wurde mitjESC unterbrochen|Was nun ?]” | 

END; 

Append(”[Weiter|Abbruch]”, s, ok); 

FormAlert(l, s, knöpf); 

weiter := (knöpf = 1); 

END Meldung; 


PROCEDURE DruckerTest; 

BEGIN 

WHILE NOT PrnOS() AND weiter DO Meldung(prnWeg) END 
END DruckerTest; 


PROCEDURE FileTest(f: File); 

BEGIN 

WHILE (State(f) < 0) AND weiter DO ResetState(f); Meldung(fileWeg) END 
END FileTest; 

PROCEDURE TastaturTest; 

VAR taste : CHAR; 

BEGIN 

InOut.BusyRead(taste); 

IF taste = ESC THEN Meldung(pause) END 
END TastaturTest; 


PROCEDURE DruckerVorbereiten; 

VAR 

BEGIN 


(* Die folgenden Einstellungen ....*) 
(* ...gelten für Epson Drucker... *) 
(* ... nach eigenem Gerät anpassen!*) 


Create(prn, ”PRN:”,writeSeqTxt,noReplace); 
DruckerTest; 

IF weiter THEN 

Write(prn,ESC); Write(prn,”M”); 

Write(prn,ESC); Write(prn,”C”); 

Write(prn,ESC); Write(prn,”1”); 

Write(prn,ESC); Write(prn,”R”); Write(prn,OC); 
END; 

Close(prn) 

END DruckerVorbereiten; 


Write(prn, ”H”); 
Write(prn,14C); 


(* Drucker öffnen *) 


(* Elite-Schrift *) 
(* 72 Zeilen/Seite*) 
(* linker Rand 12 *) 
(* am. Zeichensatz*) 
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PROCEDURE WaehleEile(VAR Pfad, DateiName, VollerName: ARRAY OP CHAR): BOOLEAN; 
VAR 

i : CARDINAL; 

FsOk, ok : BOOLEAN; 

BEGIN 

SelectPile(Pfad, DateiName, PsOk); 
i := Length(Pfad); 

REPEAT DEC(i) UNTIL Pfad[i] = ”\”; 

Copy(Pfad, 0, i+ 1, VollerName, ok); 

Append(DateiName, VollerName, ok); 

RETURN PsOk 
END WaehlePile; 

PROCEDURE PilesAuswaehlen; (* Wählt alle zu druckenden Piles aus...*) 

VAR 

FileName, Pfad, Pileldent: String; 

BEGIN 

FileName : = 

Pfad := StandardPfad; (* voreingestellter Pfad *) 

WHILE WaehlePile(Pfad, FileName, Fileident) DO 
InOut.WriteLn; InOut.WriteString(FileName); 

Schlange.Anfuegen(schlänge,Fileident); 

END 

END FilesAuswaehlen; 

PROCEDURE DruckeEinFile(f: File; Titel: ARRAY OF CHAR); 

VAR zeile,seite : CARDINAL; 

Seitenzahl : String; 
ch : CHAR; 

PROCEDURE SonderZeichen(nr : CARDINAL); 

(* Anpassung für dt. Zeichen beim Epson FX80, für andere Drucker abändern. *) 
(* Es wird jeweils der dt. Zeichensatz eingeschaltet, das Zeichen gedruckt,*) 
(* und dann wieder auf den amerikanischen Zeichensatz umgeschaltet. *) 

BEGIN 

Write(prn,ESC); Write(prn,”R”); Write(prn,2C); (* dt. Zeichensatz ein *) 

Write(prn,CHR(nr)); 

Write(prn,ESC); Write(prn,”R”); Write(prn, OC) (* am. Zeichensatz ein *) 

END SonderZeichen; 

BEGIN 

seite:-1; 

InOut.WriteLn; InOut.WriteString(”- Druck von: ”); InOut.WriteString(Titel); 
Write(prn,Fett); WriteString(prn, Titel); (* Kopfzeile ohne Seitennummer*) 
WriteLn(prn); WriteLn(prn); 
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zeile:=3; 

WHILE (NOT EOF(f)) AND weiter DO 


IE zeile MOD ZpS = 0 THEN 
INC(Seite); 

Write(prn,EP); 

Write(prn, Eett); 
WriteString(prn, Titel); 
WriteString(prn, ” 


Seite ”); 


(* Kopfzeile mit Seitennr. *) 


(* Seitenende ? *) 


(* Form Eeed *) 
(* Fettdruck *) 


Seitenzahl:=CardToStr(LONG(seite), 0); 

WriteString(prn,Seitenzahl); 

WriteLn(prn); WriteLn(prn); 
zeile:=3; 

END; 

Read(f, ch); 

IE EOL(f) THEN (* Zeilenende? *) 

WriteLn(prn); INC(zeile) 

ELSE 

OASE ch OF 

”ß” : SonderZeichen(126) t 
”&” : SonderZeichen(123) | 

”ü” : SonderZeichen(125) | 

”ö” : SonderZeichen(124) ! 

”Ä” : SonderZeichen( 91) | 

”Ü” : SonderZeichen( 93) | 

”Ö” : SonderZeichen( 92) | 

”§” : SonderZeichen( 64) 

ELSE Write(prn, ch) 

END 

END; 

TastaturTest; 


END; 

Write(prn, FE) 


(* Seitenvorschub für die letzte Seite *) 


END DruckeEinFile; 


PROCEDURE FilesDrucken; 
VAR 


Fileident, Titel: String; 


ok 


l 


f 


: CARDINAL; 
: BOOLEAN; 

: File; 


BEGIN 

Create(prn,”PRN:”, writeSeqTxt, noReplace); 
DruckerTest; 

WHILE NOT Schlange.leer(schlänge) AND weiter DO 
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Schlange.Abholen(schlänge, Fileident); 

Open(f, Fileident, readSeqTxt); 

FileTest(f); 
i := Length(FileIdent); 

REPEAT DEC(i) UNTIL Fileldent[i] = 

Copy(Fileident, i+ 1, 999, Titel, ok); 

IF weiter THEN DruckeEinFile(f, Titel) END; 
Close(f) 

END; 

Close(prn); 

END FilesDrucken; 

VAR c: CHAR; 

BEGIN 

anmelden; 

Meldung(anleitung); 

IF weiter THEN 

Schlange.Einrichten(schlange); 

DruckerVorbereiten; 

IF weiter THEN FilesAuswaehlen; FilesDrucken END; 
END; 

abmelden; 

END Druck. 


(* letztes ”\” suchen *) 
(* Filenamen herausfischen *) 


Unser Programm berücksichtigt die Steuerungssequenzen des Epson FX-80 Druckers. Auf 
der Diskette finden Sie auch eine Version für den Hewlett Packard DeskJet. Außerdem ist hier 
das Programm leicht geändert, indem ganz auf inOut verzichtet wurde, was ein erheblich 
kürzeres PRG-File bewirkt (Dateineame DruckNeu). 

Hinweis für SPC-Modula-Programmierer: durch die Benutzung der SPC-Moduls Printer 
läßt sich das Programm stark vereinfachen! 


4.5 Benutzung der Line-A-Grafik-Routinen 

Grafik läßt sich beim Atari auf zweierlei Weise erzeugen: 

1. Mittels der komfortablen GDP-Routinen (Generalized Drawing Primitives) aus VDI- 
Outputs. Darüber mehr im nächsten Abschnitt. 
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2. Durch die primitiven Line-A-Routinen. Diese sind recht maschinennah und somit sehr 
schnell. Sie sind allerdings auf den Assembler-Programmierer zugeschnitten, Megamax- 
Modula bietet eine (relativ) einfache Schnittstelle zu diesen Routinen. 

Die Line-A-Routinen werden im Megamax-System durch den Modul LineA bereitgestellt. 
Der Name »Line-A« erklärt sich von der Art und Weise, wie diese Routinen unter Assembler 
aufgerufen werden: Man setzt an die Stelle, die eine Line-A-Routine aufrufen soll, eine In¬ 
struktion, die mit dem Code »A00« beginnt. Der 68000er erzeugt dabei einen Trap, daß heißt, 
er verzweigt dabei zu einer ganz bestimmen Routine. Dabei werden keine Parameter überge¬ 
ben. Da die Routinen dennoch einiges an Parametern benötigen (Koordinaten, Färb- oder 
Musterangaben etc.), müssen diese Werte vorher bestimmten Speicherstellen - den 
»Line-A-Variablen« zugewiesen werden. Einfaches Rezept: 

1. Entsprechende Line-A-Variablen vorbelegen (hängt von der benötigten Routine ab) 

2. Die Line-A-Routine aufrufen 

Ein Beispiel: Man möchte eine durchgezogene Linie vom Punkt (100,200) nach (300,400) zie¬ 
hen. Das sieht dann so aus: 

1. Man besorgt sich einen Zeiger auf die Line-A-Variablen. Das Beispiel in Hänisch-Modula: 

VAR LineAZeiger: ParamPtr; 

dummy : ADDRESS; (* für Parameterliste *) 

BEGIN 

LineA.Init(LineAZeiger, dummy); 

2. Man belegt die erforderlichen Line-A-Variablen wie erwünscht: 

WITH LineAZeiger" DO 
xl := 100; 
x2 : = 200; 
x3 := 300; 
x4 := 400; 

LnMask := {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} 

(* Alle Bits gesetzt: durchgezogene Linie *) 

END; 


3. Man ruft Line auf (ohne Parameter): 

LineA.Line; 


Jetzt ist die Linie auf dem Bildschirm. 
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Dieses Konzept wird bei Megamax-Modula dadurch aufgeweicht, daß die Prozeduren aus 
dem Modul LineA doch mit einer Parameterliste versehen werden. Mit diesen Parametern 
belegen sie dann einige (nicht unbedingt alle nötigen) Line-A-Variablen und rufen dann die 
Line-A-Routine auf. Dies kann durchaus praktisch sein: Zum Beispiel hat hier die Routine 
PutPixel (zeichnet einen Punkt) die Koordinaten und die Farbe mit in der Parameterliste: 

PutPixel(p:Point;Parbe:CARDINAL); 

Der Typ Point muß aus Graf Base importiert werden und enthält die Punktkoordinaten als 
Verbund. 


4.5.1 Der Modul »Line-A-Grafik« 

Bei den folgenden Grafik-Programmen, die mit Line-A-Routinen arbeiten, gibt es einige 
grundlegende Anweisungsfolgen, die immer wieder benötigt werden. Um diese nicht jedesmal 
neu programmieren zu müssen, sammeln wir diese in Prozeduren und lagern sie in einem 
externen Modul aus. Ein Beispiel: Bildschirm löschen. Da es dafür keine fertige Routine gibt, 
realisieren wir dies, indem wir den gesamten Bildschirm mit einem weißem Rechteck überma¬ 
len. Damit ein möglicher Bildschirmausdruck besser aussieht, zeichnet man gleich einen 
Rahmen darum herum. 

DEFINITION MODULE LineAGrafik; 

PROCEDURE LineAHintergrund; 

(* 

* Löscht den Bildschirm mittels Line-A-Routinen 

* und setzt das Clipping auf den gesamten Bildschirm. 

*) 

END LineAGrafik. 


IMPLEMENTATION MODULE LineAGrafik; 

PROM SYSTEM IMPORT ADR; 

PROM GrafBase IMPORT Pnt, WritingMode; 

PROM LineA IMPORT Line, FilledRectangle, LineAVariables, 

PtrLineAVars, HideMouse, ShowMouse; 

CONST 

xH = 639; 

yH = 399; 
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PROCEDURE LineAHintergrund; 

CONST 

maxPattern =0; (* Anzahl der 16-Bit Patterns minus 1 *) 

VAR 

LineAVarZeiger : PtrLineAVars; 

Muster : ARRAY[0..maxPattern] OE CARDINAL; 

BEGIN 

LineAVarZeiger:=LineAVariables(); 

Muster[0]:=0; 

WITH LineAVarZeiger" DO 
patternMask:=maxPattern; 
patternPtr:=ADR(Muster); 
writingMode:=replaceWrt; 
minClip:=Pnt(0,0); 
maxClip:=Pnt(xH,yH); 
clipping:=TRUE; 

END; 

HideMouse; 

EilledRectangle(Pnt(0 } 0),Pnt(xH,yH)); (* Bildschirm löschen *) 

WITH LineAVarZeiger" DO 

planel:=TRUE; plane2:=TRUE; plane3:=TRUE; plane4:=TRUE; 
lineMask:=MAX(CARDINAL); 

END; 

Line(Pnt(0, 0),Pnt(xH,0)); (* Rahmen zeichnen *) 

Line(Pnt(xH,0),Pnt(xH,yH)); 

Line(Pnt(xH, yH),Pnt(0,yH)); 

Line(Pnt(0,yH),Pnt(0,0)); 

ShowMouse(EALSE); 

END LineAHintergrund; 

END LineAGrafik. 


4.5.2 Chaos oder Struktur 

Machen wir also endlich einen Punkt (mit PutPixel)! Da aber ein einzelner Punkt vielleicht 
etwas langweilig ist, dürften es auch ein paar mehr sein? Unser Beispielprogramm behandelt 
das folgende Problem: 
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Initialisierung: 

1. Gegeben sind drei Punkte P1, P2, P3, die nicht auf einer Geraden liegen (wir haben also die 
Ecken eines Dreiecks). 

2. Gegeben ist ein weiterer Punkt, der Startpunkt, »S« (z. B. außerhalb des Dreiecks). 
Schleife: 

1. Man wähle per Zufallsgenerator einen der Punkte PI, P2, oder P3 aus. 

2. Der Mittelpunkt einer gedachten Verbindungslinie von S nach dem ausgewählten Punkt 
wird auf den Bildschirm gezeichnet. Diese Stelle wird zum neuen Startpunkt S. 

Die Schleife läuft solange, bis eine Taste gedrückt wird. Während dieser Zeit werden laufend 
Punkte nach dem oben beschriebenen Algorithmus gemalt. Das kann doch wohl nur ein 
Punkte-Chaos werden? Oder besitzt die so entstehende »Punktwolke« doch eine Struktur? Da 
Sie keine Lust haben, es auf einem Zettel auszuprobieren, lassen Sie das nachfolgende Pro¬ 
gramm laufen. Programmtechnisch wird hier neben dem Zeichnen von Punkten auch das Ein¬ 
lesen von Koordinaten mit der Maus demonstriert. 


MODULE ChaosOderStruktur; 


EROM Terminal 
EROM RandomGen 
EROM GEMGlobals 
EROM GrafBase 
FROM AESEvents 
EROM LineA 


IMPORT KeyPressed; 

IMPORT RandomCard, Randomize; 

IMPORT MouseButton, MButtonSet, SpecialKeySet; 
IMPORT Point; 

IMPORT Buttonlvent; 

IMPORT PutPixel, HideMouse, ShowMouse; 


EROM LineAGrafik IMPORT LineAHintergrund; 


CONST maxEcken 


3; 


(* Eckenzahl des Vielecks *) 


VAR punkte 
start 

ZufallsZahl 
i 


: ARRAY[1..maxEcken] OE Point; 
: Point; 

: [1..maxEcken]; 

: CARDINAL; 


PROCEDURE MausPunkt 
VAR 

P 

knöpf 
taste 
wieoft 


Point; 


Point; 

MButtonSet; 

SpecialKeySet; 

CARDINAL; 


(* liefert einen angeklicken Punkt *) 
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BEGIN 

ButtonEvent(1, MButtonSet[msButl],MButtonSet{msButl}, p, knöpf, taste, wieoft); 

RETURN p 
END MausPunkt; 

PROCEDURE EckenUndStartpunktHolen; 

BEGIN (* Alle Ecken mit der Maus holen *) 

HideMouse; 

POR i:=1 TO maxEcken DO 
ShowMouse(PALSE); 
punkte[i]:=MausPunkt(); 

HideMouse; 

PutPixel(punkte[i], 1); 

END; 

ShowMouse(PALSE); 
start:=MausPunkt(); 

HideMouse; 

PutPixel(start, 1); 

END EckenUndStartpunktHolen; 

PROCEDURE PunkteZeichnen; 

BEGIN 

Randomize(1234); (* Zufallsgenerator initialisieren *) 

REPEAT 

ZufallsZahl:=RandomCard(1,maxEcken); 

WITH start DO 

x:=(x+punkte[ZufallsZahl]. x) DIV 2; 
y:=(y+punkte[ZufallsZahl]. y) DIV 2; 

END; 

PutPixel(start,1); 

UNTIL KeyPressed(); 

ShowMouse(PALSE); 

END PunkteZeichnen; 

BEGIN 

LineAHintergründ; 

EckenUndStartpunktHolen; 

PunkteZeichnen 
END ChaosOderStruktur. 



Systemfonts des Atari ST 


339 


Wetten, daß Sie nicht mit dem folgenden Bild gerechnet haben? 



Bild 4.5: Chaos oder Struktur? 


Bei genauer Betrachtung erkennt man, daß sich in einigen der hellen Dreiecke ein einzelner 
schwarzer Punkt befindet (einer, nicht mehr). Wo kommt er her? Wenn es nicht gerade der 
Startpunkt ist, muß er als Mittelpunkt einer Verbindungsstrecke eines der Eckpunkte PI, P2 
oder P3 und einem weiterem Punkt S entstanden sein. Dieser Punkt S liegt dann vom entspre¬ 
chenden Eckpunkt doppelt so weit weg, wie der Punkt selbst. Er stammt also aus einem dop¬ 
pelt so großem Dreieck, nämlich demjenigen, das von dem Eckpunkt auf die doppelte Ent¬ 
fernung projiziert wurde. Andersherum: wenn ein Punkt in einem (weißen) Dreieck gelandet 
ist, landet er beim nächsten Mal in einem kleineren. Weiße Dreiecke einer bestimmten Größe 
werden also nie wieder von einem schwarzen Punkt verschmutzt. 


4.5.3 Systemfonts des Atari ST 

Eine 2. Demonstration der Line-A-Routinen beschäftigt sich mit der Ausgabe von Texten auf 
dem Grafik-Bildschirm. Darum einige Vorbemerkungen zur Organisation der Text-Fonts des 
Atari-GEM: 
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Zunächst gibt es drei Systemfonts zu 6x6,8x8 und 8x16 Pixeln. Jeder dieser Fonts enthält 256 
Zeichen (der ASClI-Zeichensatz ist darin enthalten). Der Zugriff auf einen der Systemfonts 
geschieht nun über 2 Indirektionen (Verzeigerungen): 

Mit der Funktion SystemFonts erhält man einen Zeiger (vom Typ PtrSysFontHeader), 
der auf ein Feld von drei weiteren Zeigern verweist. Jeder dieser Zeiger (Typ: P t rFontHeade r) 
verweist auf einen »FontHeader«. Dies ist ein Verbund mit Informationen (unter anderem 
Größe, Höhe der Kleinbuchstaben) über die drei System-Fonts. 



Bild 4.6: Datenstruktur der Atari-Systemfonts 


Hat man sich durch diese Verzeigerung durchgehangelt, so kann man nun ein Zeichen aus ei¬ 
nem der Fonts mit der Prozedur TextBlockTransfer an beliebiger Stelle auf dem Bild¬ 
schirm ausgeben. 


MODULE VieleZufallsZeichen; 


FROM SYSTEM IMPORT VAL; 

FROM Terminal IMPORT KeyPressed; 

FROM RandomGen IMPORT RandomCard; 

FROM GrafBase IMPORT Pnt; 

FROM LineA IMPORT TextBlockTransfer, PtrFontHeader, 

SystemFont, SystemFonts, HideMouse 
FROM LineAGrafik IMPORT LineAHintergrund; 


VAR 


p : PtrSysFontHeader; 

q : PtrFontHeader; 

ch : CHAR; 

font : SystemFont; 


PtrSysFontHeader, 
, ShowMouse; 






















Systemfonts des Atari ST 


341 


BEGIN 

LineAHintergründ; 

HideMouse; 

REPEAT 

p:=SystemPonts(); (* Zeiger auf Systemfontarray 

font:=VAL(SystemFont,RandomCard(0, 2)); (* Zufallsfont auswählen 
q:=p~[font]; 

ch: =CHR(RandomCard(33, 255)) ; (* Zeichen zufällig auswählen 

(* auf den Bildschirm damit... 

TextBlockTransfer(q,ch,Pnt(RandomCard(0,639), RandomCard(0,399))); 
UNTIL KeyPressed(); 

ShowMouse(PALSE) 

END VieleZufallsZeichen. 



Bild 4.7: Zufallszeichen mit den drei Atari-Systemfonts 
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4.5.4 Rekursive Grafik 

Wunderschöne Grafiken lassen sich durch Rekursion erzeugen. Das Grundprinzip besteht 
darin, daß eine relativ einfache Figur (etwa ein Dreieck) von einer Prozedur gezeichnet wird, 
die sich mit veränderten Parametern selbst wieder aufruft und eine verschobene, gedrehte oder 
gestauchte Figur zeichnet. Bekannte Beispiele sind Hilbert- oder Sierpinski-Kurven. Im An¬ 
hang des TDI-Modula-Handbuches findet man hierfür die Beispielprogramme »Sierpinski«, 
»Diamond« und »Fractal«. Sierpinski-Kurven werden auch in [Wl] behandelt; wir greifen 
diese Beispiele daher nicht auf. 

Statt dessen lösen wir eine Aufgabe, die im Rahmen des 5. Bundeswettbewerbs Informatik ge¬ 
stellt wurde: 

»Der Baum des Pythagoras setzt sich aus lauter Quadraten zusammen, die so um rechtwink¬ 
lige Dreiecke angeordnet sind, daß sie den Satz des Pythagoras illustrieren. Ihre Seitenver¬ 
hältnisse sind 3:4:5. Die ersten Verästelungen des Baumes zeigt die Abbildung.« 



Bild 4.8: Rekursive Grafik: Der Baum des Pythagoras 
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Programmerläuterung: 

Das Programm besteht im wesentlichen aus zwei Prozeduren: 

Prozedur Linie: 

Malt einen Strich (was sonst?). Dabei rechnet sie aber die reellen »Welt«-Koordinaten in 
Bildschirmkoordinaten um. 


Prozedur ZeichneBaum: 

Malt ein Quadrat (mit Linie) und veranlaßt sich selbst, die beiden nächsten Quadrate zu 
zeichnen. 


Die Prozedur ZeichneBaum ruft sich zweimal rekursiv auf, einmal für den linken Teilbaum 
und einmal für den rechten. Wenn man das Programm laufen läßt, sieht man, daß zunächst der 
äußere rechte Ast fertig gezeichnet wird. Damit nun auch der zweite Aufruf von Ze i chneBaum 
für den linken Ast auch einmal ausgeführt wird, muß der erste irgendwann beendet werden. 
Da sich Baum und jeder Ast aber eigentlich beliebig oft verzweigt, muß irgendwo eine 
Schranke gesetzt werden. Wir machen das, indem wir die Rekursionstiefe mitzählen: Es wird 
eine Variable tiefe mitgeführt, die bei jedem Aufruf um eins erniedrigt wird. Wenn sie bei 0 
gelandet ist, hört die Prozedur auf, sich selbst aufzurufen. Wir beschränken also die Rekur¬ 
sionstiefe. 


MODULE PythagorasBaum; 

PROM Terminal IMPORT KeyPressed; 

PROM MathLibO IMPORT entier; 

PROM GrafBase IMPORT Pnt; 

FROM LineA IMPORT Line, HideMouse, ShowMouse; 

PROM LineAGrafik IMPORT LineAHintergrund; 


CONST 


xH = 639; 

yH = 399; 

xM = xH DIV 2; 

RekursionsTiefe = 12; 

PROCEDURE Linie(xl,yl, x2,y2 : REAL); 
VAR X1,Y1,X2,Y2 : INTEGER; 

BEGIN 

XI:=xM + SHORT(entier(xl)); 

Yl:=yH - SHORT(entier(yl)); 

X2:=xM + SHORT(entier(x2)); 

Y2:=yH - SHORT(entier(y2)); 
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Line(Pnt(XI,Y1),Pnt(X2, Y2)) 

END Linie; 

PROCEDURE ZeichneBaum(aX,aY, bX, bY : REAL; tiefe : INTEGER); 
VAR cX,cY,dX,dY,eX,ey,IX,1Y : REAL; 


BEGIN (* . E. . *) 

IF tiefe > 0 THEN (* / c *) 

IX:=aY-bY; 1Y:=bX-aX; (* D-C *) 

cX:=bX+lX; eY:=bY+lY; (* | | *) 

dX:=aX+lX; dY:=aY+lY; (* | i *) 

Linie(aX,aY,bX,bY); Linie(bX, bY, cX, cY); (* A-B *) 

Linie (cX, cY, dX, dY); Linie (dX, dY, aX, aY); 


eX: =dX + 0.36*(cX-dX) + 0.48*1X; ey:=dY + 0.36*(cY-dY) + 0. 48*1Y; 
ZeichneBaum(eX,ey,cX,cY,tiefe-1); ZeichneBaum(dX, dY, eX, ey,tiefe-l) 

END 

END ZeichneBaum; 

BEGIN 

LineAHintergründ; 

HideMouse; 

ZeichneBaum(-FLOAT(xH DIV 16),0.0,FLOAT(xH DIV 16),0.0,RekursionsTiefe); 
REPEAT UNTIL KeyPressed(); 

ShowMouse(FALSE) 

END PythagorasBaum. 


4.5.5 Ein Ausflug in die fraktale Geometrie 

Zum Schluß noch ein spektakuläres Beispiel: Es geht um die »Mandelbrot-Menge« (benannt 
nach dem polnischen Mathematiker Benoit B. Mandelbrot) oder besser bekannt unter dem 
saloppen Namen »Apfelmännchen«. 

Wir betrachten eine beliebige komplexe Zahl (vgl. Abschnitt 1.7.3) 
c = a+bi 

Dann setzen wir eine komplexe Variable z : = 0 und berechnen fortlaufend 
z := z 2 +c 

Die Mandelbrotmenge ist nun die Menge aller derjenigen Komplexen Zahlen c, für die der Be¬ 
trag von z nach beliebig häufiger Iteration (z : = z 2 +c)nicht ins Unendliche wächst. Aus 
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der Theorie benutzen wir das einfache Resultat, nach dem c nicht zur Mandelbrotmenge ge¬ 
hört, sobald irgendwann einmal |z| >2 wird. 

Da wir allerdings nicht unendlich oft rechnen können, beschließen wir, c schon zur Mandel¬ 
brotmenge zu zählen, falls für |z| nach einer bestimmten Zahl von Iterationen (nach etwa 
lOOmal) immer noch |z| < 2 gilt. Markiert man in der komplexen Zahlenebene alle Punkte 
der Mandelbrotmenge, so ergibt sich eine Figur, das »Apfelmännchen«. 

Diese Figur befindet sich im Bereich der Koordinaten [-1. 2 ; 1. 2 ] auf der imaginären Achse 
und [-2. 25; 0. 75] auf der reellen Achse. Besonders einige Stellen am Rande des Apfelmänn¬ 
chens ergeben bei entsprechender Vergrößerung recht interessante Gebilde. Apfelmännchen 
sind also eigentlich ganz einfach, nur die Umrechnung eines komplexen Punktes in Bild¬ 
schirm-Koordinaten ist etwas umständlich. 

Hier das Programm: 

MODULE MandelbrotMenge; 

FROM Terminal IMPORT BusyRead; 

PROM ComplexLib IMPORT complex, cmplx, sqrc, addc, abs2; 

PROM GrafBase IMPORT Pnt; 

PROM LineA IMPORT PutPixel, HideMouse, ShowMouse; 

PROM LineAGrafik IMPORT LineAHintergrund; 

PROM Sound IMPORT Wecker; 

CONST 


minRe 

= 

-2. 5; 

(* Begrenzungen der komplexen Zahlenebene 

*) 

minim 

= 

-1.2; 



maxRe 

= 

1. 34; 

(* Anpassung an das Seitenverhältnis 640/400 

*) 

maxlm 

= 

1. 2; 



Tiefe 

= 

30; 

(* Iterationstiefe für z:= z~2 + c 

*) 

xH 

= 

639; 

(* Bildschirmbegrenzung in Pixeln 

*) 

yH 

= 

399; 




VAR 

steigungX, steigungY, pX, pY : REAL; 

x,y : INTEGER; 

taste : CHAR 

PROCEDURE rechnePunkt(c : complex) : CARDINAL; 

VAR i : CARDINAL; 

z : complex; 

BEGIN 


z : = cmplx(0. 0,0.0); 
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FOR i:=0 TO Tiefe - 1 DO 

z:=addc(sqrc(z),c); (* z:= z~2 + c *) 

IF abs2(z) >= 4.0 THEN RETURN i END 
END; 

RETURN Tiefe 
END rechnePunkt; 

PROCEDURE Iteration; 

BEGIN 

FOR x:=0 TO xH DO 

BusyRead(taste); IF taste = 33C THEN RETURN END; (* ESC =>Abbruch *) 
pX := minRe + steigungX * FLOAT(x); 

FOR y:=0 TO yH DO 

pY : = minim + steigungY * FLOAT(y); 

IF rechnePunkt(cmplx(pX,pY)) = Tiefe THEN PutPixel(Pnt(x,y),1) END 
END 
END; 

END Iteration; 

BEGIN 

LineAHintergründ; 

HideMouse; 

steigungX := (maxRe - minRe) / FLOAT(xH + 1); 
steigungY := (maxlm - minim) / FLOAT(yH + 1); 

Iteration; 

Wecker; 

REPEAT BusyRead(taste) UNTIL taste = 33C; (* Warten auf ESC *) 

ShowMouse(FALSE) 

END MandelbrotMenge. 


Schon bei der relativ kleinen Iterationstiefe von 30 ergibt sich folgendes Bild, das die Auf¬ 
lösung des Atari-Bildschirmes völlig ausnutzt: 
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Bild 4.9: Gesamtbild der Mandelbrotmenge 

Möchte man die recht verworrenen Randbereiche genauer unter die Lupe nehmen, so braucht 
man im Programm nur die ersten 4 Konstanten auf den gewünschten Bereich zu setzen. Inter¬ 
essant sind unter anderem folgende Werte: 

minRe =-1.254024maxRe =- 1.252861; 
minim = 0.046252piaxlm = 0.047125; 

Tiefe = 200; 

Sie finden das so abgewandelte Programm auf der Begleitdiskette unter dem Namen 
»MANDELB2. M«. Die verschiedenen Schwarzweißstufungen haben wir dadurch erreicht, daß 
nur bei ungradzahliger Tiefe ein Punkt gezeichnet wird. Entsprechend ließen sich für einen 
Farbmonitor unterschiedliche Farben einsetzen. Der Term Tiefe MOD FarbAnzahl be¬ 
stimmt die Farbe des Bildpunktes. 
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Bild 4.10: Vergrößerter Ausschnitt aus der Mandelbrotmenge (I) 


Nur bei angemessener Tiefe erhält man solche eindrucksvollen Grafiken. Man sollte sich also 
hierfür genügend Zeit lassen und den Rechner ruhig eine Nachtschicht einlegen lassen. Weil es 
so schön ist, folgt noch ein weiterer Ausschnitt aus der Mandelbrotmenge mit den Grenzen: 


minRe =-0.74591; maxRe =-0.74448; 
minim = 0.11196;maxlm = 0.11339; 
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Bild 4.11: Vergrößerter Ausschnitt aus der Mandelbrotmenge (II) 


Die Abbildungen zeigen, daß man an die Grenzen der Bildschirmauflösung stößt. Sollten Sie 
noch anspruchsvoller sein, empfiehlt es sich, die höhere Auflösung eines Druckers auszunut¬ 
zen. Leiten Sie dazu die Ausgabe auf ein File von Bytes, statt auf den Bildschirm. Lediglich die 
Routine PutPixel muß dazu geändert werden: Ein schwarzer Punkt entspricht einem gesetz¬ 
ten Bit. Nun muß noch ein kleines Ausdrucksprogramm her! 

Die Mandelbrotmenge hat viel Rechenzeit auf Rechnern überall in der Welt gekostet, warum 
sollte es auf Ihrem Atari anders sein? 

Juliamengen 

Durch eine kleine Modifikation des Mandelbrot-Programmes erhält man völlig andersartige 
Bilder. Hält man c konstant und besetzt z mit dem jeweiligen Punkt, so erhält man die 
»Julia-Mengen« (nach dem französischem Mathematiker Gaston Julia). Für c wählt man 
einen Punkt aus der Mandelbrot-Menge. 

Für folgende Abbildung haben wir 

c =-0.74543 + 0.11301 i 

gewählt, einen Punkt im sogenannten »Seepferdchen-Tal«. Änderungen von c machen sich 
durch drastischen Änderung der Julia-Menge bemerkbar. 
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Bild 4.12: Eine Julia-Menge 


MODULE JuliaMenge; 


FROM 

FROM 

FROM 

FROM 

FROM 

FROM 


Terminal IMPORT KeyPressed; 
ComplexLib IMPORT complex, cmplx, sqrc 
G-rafBase IMPORT Pnt; 

LineA IMPORT PutPixel, HideMouse, 

LineAGrafik IMPORT LineAHintergrund; 
Sound IMPORT Wecker; 


addc, abs2; 
ShowMouse; 


CONST 


minRe 

= 

-1.7; 

(* Begrenzungen der komplexen Zahlenebene *) 

minim 

= 

-1.0; 


maxRe 

= 

1. 7; 


maxlm 

= 

1.0; 


Tiefe 

= 

200; 

(* Iterationstiefe für z: = z~2 + c *) 

xH 

= 

639; 

(* Bildschirmbegrenzung in Pixeln *) 

yH 


399; 
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VAR 

steigungX, steigungY, pX, pY : REAL; 
x,y : INTEGER; 

c : complex; 

PROCEDURE rechnePunkt2(z : complex) : CARDINAL; 

VAR i : CARDINAL; 

BEGIN 

EOR i:=0 TO Tiefe DO 
z:=addc(sqrc(z),c); 

IE abs2(z) >= 4.0 THEN RETURN i END 
END; 

RETURN Tiefe 
END rechnePunkt2; 

PROCEDURE Iteration; 

BEGIN 

FOR x:=0 TO xH DO 

IF KeyPressed() THEN RETURN END; 
pX := minRe + steigungX * FLOAT(x); 

FOR y:=0 TO yH DO 

pY := minim + steigungY * FLOAT(y); 

IF rechnePunkt2(cmplx(pX,pY)) = Tiefe THEN PutPixel(Pnt(x,y),1) END 
END 
END; 

Wecker; 

END Iteration; 

BEGIN 

LineAHintergründ; 

HideMouse; 

steigungX := (maxRe - minRe) / FLOAT(xH + 1); 
steigungY := (maxlm - minim) / FLOAT(yH + 1); 

c := cmplx(-0.74543,0.11301);(* Startpunkt am Rand der Mandelbrotmenge, . .*) 

(* wo sich die beiden großen Gebiete treffen *) 

Iteration; 

REPEAT UNTIL KeyPressed(); 

ShowMouse(FALSE) 

END JuliaMenge. 
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Einige Vorschläge für die Konstante c zum Experimentieren mit dem Programm: 


reell 

imaginär 




0 

0 

im Zentrum 

der Mandelbrotmenge 

0. 31 

0. 04 




-0. 11 

0.6557 




-0. 12 

0. 74 




0 

1 




-0.194 

0.6557 

sehr 

schöne 

Julia-Menge 

-1. 25 

0 




-0.481762 

-0.531657 




-0.39054 

-0.58679 




-0.15652 

-1.03225 




0.11031 

-0.67037 




0.27334 

0.00742 

sehr 

schöne 

Julia-Menge 


Die Werte sind dem Buch [P] entnommen, was demjenigen empfohlen werden kann, der sich 
in die mathematische Theorie einarbeiten möchte. Außerdem enthält es hinreißende Farbgra¬ 
fiken. 

Der Mandelbrotmenge und den Julia-Mengen liegen »fraktale« Strukturen zu Grunde. Ihr 
Rand ist »unendlich stark« zergliedert. Diese diffizile Struktur kommt um so stärker zum 
Ausdruck, je größer die Tiefe gewählt wird. Natürlich erhöht das auch die Rechenzeit. 
Deutlich schnellere Rechenzeiten lassen sich auf dem Atari nur erreichen, wenn man mit Inte- 
ger-Arithmetik arbeitet. Der größte Teil der Zeit wird durch für das Rechnen mit REAL- 
Zahlen verwendet, wobei insbesondere die Multiplikation zu Buche schlägt. Selbst eine Pro¬ 
grammierung in Assembler bringt daher wenig. 


4.6 Benutzung der VDI-Grafik-Routinen 

Mit den 16 Line-A-Routinen, die im vorigen Abschnitt besprochen wurden, lassen sich 
Punkte, Linien, ausgefüllte Rechtecke und Polygone zeichnen. Sie stellen somit die grundle¬ 
genden Ausgabefunktionen auf dem Atari dar, das gesamte GEM benutzt sie (siehe Grafik 
unter Abschnitt 4.1). Insbesondere stützen sich auch die VDI-GrafikProzeduren auf diese 
Routinen. Die VDI-Routinen arbeiten daher nicht so schnell, stellen aber komfortablere Nut¬ 
zungsmöglichkeiten bereit. Sämtliche Beispiele des vorigen Abschnittes sind natürlich auch 
als VDI-Grafik realisierbar! 

Die VDI-Ausgabefunktionen werden durch den Modul VDlOutputs bereitgestellt. Dort 
stehen auch komplexere Funktionen wie zum Beispiel Ausfüllen von Flächen mit diversen 
Mustern zur Verfügung. Unter anderem gibt 10 »Generalized Drawing Primitives« (im fol- 
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genden GDP, etwa »allgemeine Zeichen-Grundfunktionen«) zum Zeichnen von einfachen 
geometrischen Figuren, zum Beispiel: Circle (ausgefüllter Kreis), ElliptPie (ausgefüllter 
Ellipsensektor) usw. 

Alle Winkelangaben sind ganzzahlig in l/10tel Grad. Die Füllattribute (Füllmuster), Linien¬ 
attribute (Strichstärke) und Textattribute (Fontgröße) sind vor Benutzung der GDP- Routi¬ 
nen einzustellen. 


4.6.1 Der externe Modul »Grafik« 

Bevor man anfängt, Anwendungen mit VDI zu programmieren, sollte man sich über eine ge¬ 
meinsame Schnittmenge von Routinen klar werden, die man in den verschiedenen Program¬ 
men benötigt. Diese Prozeduren gehören natürlich »Modula-gerecht« in einen externen Mo¬ 
dul Grafik. Dadurch läßt sich die Programmierung mit VDI deutlich vereinfachen. 

Solche immer wiederkehrenden Probleme sind: 

• An- und Abmelden beim GEM 

• Bildschirm löschen 

• Clipping-Bereiche setzen 

• Maustasten abfragen 

• Text ausgeben 

Mit dem Modul Grafik sind diese Aufgaben in einem einfachen Prozeduraufruf zu erledi¬ 
gen. Außerdem kann man, wenn man sich die Quelltexte der Funktionen ansieht, schnell er¬ 
kennen, welche Schritte ohne diesen Modul nötig wären bzw. nötig sind, sofern man einen 
eigenen Grafik-Modul schreiben will. Unser Modul stellt neben den Prozeduren noch einige 
Variablen bereit: 

Geraet: 

Eine Variable vom Typ Devi ceHandle; sie wird bei jeder VDI-Routine benötigt und steht 
nach anmelden automatisch zur Verfügung 

ArbeitsParm: 

Ein Verbund, der sich die Koordinaten des aktuellen Arbeitsbereiches merkt. Mit ihm hat 
der Programmierer, der Grafik benutzt, im allgemeinen nichts zu tun. 

Eine normale Anwendung dieses Moduls sieht also wie folgt aus: 

MODULE GrafikDemo; 

PROM Grafik IMPORT anmelden, abmelden, Hintergrund, Arbeitsbereich; 

<. . . > 


BEGIN 
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anmelden; 

Hintergrund; 

<eigene Anweisungen> 
abmelden 
END GrafikDemo. 


Durch die Einführung dieses Moduls werden die nachfolgenden Programme nicht nur ver¬ 
ständlicher, sondern auch unabhängiger vom verwendeten Modula-System. Wenn Sie diesen 
Modul für Ihr System anpassen, sind auch für nicht-Megamax-Benutzer die Programme 
leicht übertragbar. 


DEFINITION MODULE Grafik; 

(* 

* Faßt einige häufig benutzte Grafikgrundfunktionen des VDI 

* zusammen, so daß sie ”ohne lange Vorrede” aufgerufen 

* werden können. 

*) 

FROM GEMEnv IMPORT DeviceHandle; 


VAR Geraet 
('* 


: DeviceHandle; 

Das Ausgabegerät ist beim Atari immer der Bildschirm. 

Sein Device-Handle ( = Kennung) wird für zusätzlich benutzte 
VDI-Routinen von der folgenden Prozedur ”anmelden” bereit¬ 
gestellt. ”anmelden” muß dazu am Beginn des Programmoduls 
aufgerufen werden. 


*) 


VAR ArbeitsBereich 


RECORD 

xMin, yMin, xMax, yMax: INTEGER 
END; 


Dies sind die Ausmaße des Grafik-Arbeisbereichs in Bildschirm- 
Koordinaten (links,oben) (rechts,unten). Der Verbund wird 
durch die Routine ”SetzeBereich” initialisiert. Das Anwender¬ 
programm sollte nur lesend darauf zugreifen! 




PROCEDURE anmelden; 

(* 

* Meldet unsere GEM-Anwendung beim GEM an und 

* holt sich die Kennung ”Geraet”. 
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* Diese Prozedur ist stets vor der Arbeit mit GEM aufzurufen. 
*) 

PROCEDURE abmelden; 

c* 

* Meldet die Anwendung beim GEM ab. 

* Diese Prozedur ist stets nach der Arbeit mit GEM aufzurufen. 
*) 

PROCEDURE Hintergrund; 

(* 

* Füllt den gesamten Bildschirm mit einem "grauen” Raster. 

*) 

PROCEDURE SetzeBereich(xl,yl, x2,y2: INTEGER); 

(* 

* Füllt ein Rechteck mit der linken, oberen Ecke (xl,yl) 

* und der rechten unteren Ecke (x2,y2) weiß. 

* Um das Rechteck wird ein Rahmen und rechts unten 

* ein Schatten gezeichnet. "Arbeitsbereich” wird initialisiert. 

* Außerdem wird Clipping für diesen Bereich eingeschaltet. 

* Damit ist ein Ausgabebereich für Grafik installiert. 

*) 

PROCEDURE Plot(x,y: INTEGER); 

(* 

* Zeichnet den Punkt (x,y). 

*) 

PROCEDURE Move(x,y: INTEGER); 

(* 

* Bewegt den "Zeichenstift” ohne zu Zeichnen nach (x,y). 

*) 

PROCEDURE Draw(x,y: INTEGER); 

(* 

* Zieht eine Linie vom bisherigen Ort zu (x,y). 

*) 

PROCEDURE HoleMaus(VAR x,y: INTEGER); 

(* 

* Diese Prozedur wartet auf das Klicken der linken Maustaste. 

* Sie übergibt dann die Mauskoordinaten (x,y). 

*) 



356 


Benutzung von VDI-Grafik-Routinen 


PROCEDURE Schreibe(x,y: INTEGER; art: CARDINAL; text: ARRAY OP CHAR); 
(* 

* ”text” wird ab (x,y) auf den Bildschirm geschrieben. 

* Bei art=l wird der 6*6, bei art=2 der 8*8, bei art = 3 der 

* 16*8 System-Zeichensatz verwandt; art=4 verwendet einen 

* 30*15 Pixel großen Satz ”outlined” (für Überschriften). 

*) 

END Grafik. 


Der Implementationsmodul ist etwas heißer. Wenn sie gleich zu den Grafikanwendungen vor¬ 
stoßen wollen, sollten sie ihn überschlagen. 

In der Prozedur SetzeBereich haben wir bewußt keine Fenstertechnik eingesetzt, da Fen¬ 
ster sich nicht in einem Programm mit den Textfenstern aus dem Modul TextWindows von 
Megamax vertragen. Der Hersteller wird diesen Fehler von TextWindows aber abstellen. 


IMPLEMENTATION MODULE Grafik; 


PROM 

GrafBase 

IMPORT 

PROM 

GEMGlobals 

IMPORT 

PROM 

GEMEnv 

IMPORT 

PROM 

AESWindows 

IMPORT 

PROM 

AESEvents 

IMPORT 

PROM 

AESGraphics 

IMPORT 

PROM 

VDIControls 

IMPORT 

PROM 

VDIOutputs 

IMPORT 

PROM 

VDIAttributes 

IMPORT 

PROM 

VDIInputs 

IMPORT 


white, black, Rectangle, Reet, Point, Pnt; 
FillType, TEffectSet, TextEffect, 
MouseButton, MButtonSet, SpecialKeySet; 

RC, DeviceHandle, GemHandle, 

InitGem, ExitGem, CurrGemHandle; 

DeskHandle, WindowSize, WSizeMode; 
ButtonEvent; 

GrafMouse, arrow; 

SetClipping; 

GrafText, PillRectangle, Line, PolyLine; 
SetPillType, SetPillColor, SetPilllndex, 
SetTextColor, SetTextEffects, SetAbsTHeight; 
HideCursor, ShowCursor; 


VAR 


GemKennung : GemHandle; (* wird zum An- und Abmelden benötigt *) 

AltesX,AltesY: INTEGER; 


Initialisierungs-Prozeduren 


PROCEDURE anmelden; 

VAR ok: BOOLEAN; 

BEGIN 

InitGem(RC, Geraet, ok); (* Unser Programm beim GEM anmelden *) 
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IE NOT ok THEN HALT END; 
GemKennung := CurrGemHandle(); 
GrafMouse (arrow, NIL); 

END anmelden; 


(* GEM will nicht => brutal Abbrechen *) 


PROCEDURE abmelden; 

BEGIN 

ExitGern(GemKennung) 

END abmelden; 

PROCEDURE Hintergrund; 

BEGIN (* Es wird immer vorausgesetzt, daß die Maus da ist *) 

HideCursor(Geraet); (* Maus immer beim Zeichnen verstecken *) 

SetEillIndex(Geraet, 4); (* Füllmuster waehlen *) 

SetFillType(Geraet, dottPattern); 

EillRectangle(Geraet, WindowSize(DeskHandle, borderSize)); (* alles *) 

ShowCursor(Geraet, EALSE); 

END Hintergrund; 

PROCEDURE SetzeBereich(xl,yl, x2,y2: INTEGER); 

VAR bereich : Rectangle; 

EckPunkte: ARRAY [0..4] OE Point; 
i : INTEGER; 


BEGIN 

WITH ArbeitsBereich DO 

xMin := xl; yMin := yl; xMax := x2; yMax : = y2 
END; 

bereich := Rect(xl, yl, x2-xl+ 1, y2-yl+l ); 

HideCursor(Geraet); 

SetEillColor(Geraet, white); 

SetEillType(Geraet, solidEill); 

SetClipping(Geraet,WindowSize(DeskHandle, borderSize)); 


EillRectangle(Geraet, bereich); 

EckPunkte[0]:=Pnt(xl,yl); EckPunkte[1]:=Pnt(x2, yl); 
EckPunkte[2]:=Pnt(x2,y2); EckPunkte[3]:=Pnt(xl,y2); 
EckPunkte[4]:=EckPunkte[0]; 

PolyLine(Geraet, Eckpunkte, 4); (•> 

INC (xl, 2); INC(yl, 2); (* 

EOR i:=l TO 3 DO 

EckPunkte[0]:=Pnt(x2+i, yl); EckPunkte[1]: =Pnt(x2+i, y2+i); 
EckPunkte[2]:=Pnt(xl,y2+i); 

PolyLine(Geraet,EckPunkte, 2) 

END; 


(* Fläche weiß füllen *) 
(* für den Rahmen *) 


Rahmen zeichnen *) 
für den Schatten *) 
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SetClipping(Geraet, bereich); 

ShowCursor(Geraet,PALSE) 

END SetzeBereich; 

(* =========== Grundlegende Grafik-Prozeduren ============ *) 

PROCEDURE Plot(x,y: INTEGER); 

BEGIN 

Line(Geraet, Pnt(x,y), Pnt(x,y)) 

END Plot; 

PROCEDURE Move(x, y: INTEGER); 

BEGIN 

AltesX := x; 

AltesY := y 
END Move; 

PROCEDURE Draw(x, y: INTEGER); 

BEGIN 

Line(Geraet, Pnt(AltesX,AltesY), Pnt(x,y)); 

AltesX := x; 

AltesY := y 
END Draw; 

(* ============= Maus und Text in der Grafik ============= *) 

PROCEDURE HoleMaus(VAR x,y: INTEGER); 

VAR 

p : Point; 

knöpf : MButtonSet; 
taste : SpecialKeySet; 
wieoft: CARDINAL; 

BEGIN 

ButtonEvent(1,MButtonSet{msButl,msButl), MButtonSet{msButl, msBut2), 
p, knöpf,taste,wieoft); 

IP knöpf = MButtonSet(msButl) THEN x := p. x; y : = p. y END; 

END HoleMaus; 

PROCEDURE Schreibe(x,y: INTEGER; art : CARDINAL; text: ARRAY OP CHAR); 
VAR dummy, hoehe : CARDINAL; 

BEGIN 

HideCursor(Geraet); 

SetTextColor(Geraet, black); 

SetTextEffects(Geraet, TEffectSet{}); 


(* Normalschrift *) 
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CASE art OF 

1 : hoehe:=4 (* 6*6 Fond *) 

2 : hoehe:=6; (* 8*8 Fond *) 

3 : hoehe:=13 | (* 8*16 Fond *) 

4 : hoehe: =25; SetTextEffects(Geraet,TEffectSet{outlineText)) (*15*30*) 

ELSE hoehe:=13 END; 

SetAbsTHeight(Geraet,hoehe,dummy,dummy, dummy, dummy); 

GrafText(Geraet, Pnt(x,y), text); 

ShowCursor(Geraet,FALSE) 

END Schreibe; 

END Grafik. 


4.6.2 Erstellung von Tortendiagrammen 


Als erste VDI-Grafik-Anwendung zeigen wir eine 
Tortengraflk (auch »Kreisdiagramm«). Der Prozedur 
Torte wird dazu der Mittelpunkt und der Radius des 
Kreises übergeben, sowie ein offenes Feld von Werten 
einer beliebigen Statistik. Die Prozedur rechnet diese 
Werte in die entsprechenden Winkelmaße um und be¬ 
nutzt die VDI-Routine Pie zum Zeichnen eines aus¬ 
gefüllten Kreissegmentes. Die Zeichnung beginnt 
oben und füllt die Segmente im Kreisdiagramm mit 
jeweils einem anderem Füllmuster. Die Winkelmaße 
werden in Zehntel Grad gemessen. Anfangs wird für 
90° äquivalent 450° genommen, damit die Winkel 
beim Subtrahieren positiv bleiben. 


Bild 4.13: Ein Tortendiagramm 



MODULE TortenGrafik; 


FROM VDIAttributes 

FROM AESEvents 
FROM VDIInputs 
FROM VDIOutputs 
FROM GEMGlobals 
FROM GrafBase 
FROM Grafik 


IMPORT SetFillType, SetFilllndex, SetFillColor, 
SetFillPerimeter; 

IMPORT KeyboardEvent; 

IMPORT HideCursor, ShowCursor; 

IMPORT ElliptPie; 

IMPORT FillType, GemChar; 

IMPORT Point,Pnt,black; 

IMPORT anmelden, abmelden, Geraet, Schreibe, 
Hintergrund, SetzeBereich; 
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PROCEDURE Torte(mitte : Point; radius : CARDINAL; werte : ARRAY OP REAL); 

VAR 

i, AltWinkel, NeuWinkel, yradius : CARDINAL; 
summe, akku : REAL; 

BEGIN 

summe : = 0.0; 

POR i : = 0 TO HIGH(werte) DO summe := summe + wertefi] END; 

SetFillType(Geraet, dottPattern); (* schwarzen Rand voreinsteilen *) 

SetPillColor(Geraet, black); 

SetPillPerimeter(Geraet, TRUE); 

HideCursor(Geraet); (* Maus stört beim Zeichnen *) 

akku : = 0. 0; AltWinkel := 0; 

yradius := radius * 9 DIV 10; (* zum Ausgleich der Verzerrung --> Kreis *) 

POR i : = 0 TO HIGH(werte) DO 

SetPillIndex(Geraet, i MOD 24+1); (* Püllmuster setzen *) 

akku := akku + werte[i]; 

NeuWinkel := SHORT(TRUNC(akku * 3600.0 / summe)); 

ElliptPie(Geraet,mitte,radius,yradius, 4500 - NeuWinkel, 4500 - AltWinkel); 
AltWinkel := NeuWinkel 
END; 

ShowCursor(Geraet, FALSE) 

END Torte; 


VAR 


Testwerte : ARRAY [0..5] OP REAL; 
dummy : GemChar; 


BEGIN 

Testwerte[0] : = 55.5; 

Testwerte[l] := 13.7; 

Testwerte [2] :■= 30.0; 

Testwerte[3] := 25.9; 

Testwerte[4] := 36.8; 

Testwerte[5] := 18.1; 
anmelden; 

Hintergrund; 

SetzeBereich(9,9, 630, 390); 

Schreibe(184, 50, 3, "Demonstration einer Tortengrafik”); 
Torte(Pnt(300,200), 100, Testwerte); 

KeyboardEvent(dummy); 
abmelden; 

END TortenGrafik. 
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4.6.3 VDI-Grafik-Textausgabe 

Mit der Routine »GrafText« läßt sich Text in VDI-Grafiken ausgeben. Sie baut auf den 
Systemfonts auf, die in den Größen 6x6,8x8 und 8x 16 Pixel vorhanden sind. Es ist aber durch 
Setzen der »Absoluten Textgröße« eine Vergrößerung möglich. Einen Überblick gibt die fol¬ 
gende Bildschirmkopie. 


Zeichensau flb sh : 4, 6 X 6 

Z^ichencatz RbsH: 5-, 7 * 7 

Zeichensatz AbsH: 6, 8 * 8 

Zeichensatz AbsH: 7, 9 9 

Zeichensatz AbsH: 8 r 11 * 10 

Zeichensatz AbsH: 3 , 12 » 11 

Zeichensatz AbsH: 10 . 13 13 

Zeichensatz AbsH: 11, 15 * 14 

Zeichensatz AbsH: 13, 8 * 16 
Zeichensatz AbsH: 14, 9 * 17 
Zeichensatz AbsH: 15, 9 # 18 

Zeichensatz AbsH: 16, IQ * 19 
Zeichensatz AbsH: 17, 1B * ZI 
Zeichensatz AbsH: 18, 11 * 22 
Zeichensatz AbsH: 19, 12 # 23 


Zeichensatz AbsH: 20. 12 # 24 
Zeichensatz RbsH: 21. 13 # 25 
Zeichensatz AbsH: 22. 14 # 26 
Zeichensatz RbsH! 23. 14 * 28 
Zeichensatz RbsH: 24. 15 * 25 
Zeichensatz RbsH: 25, 15 * 30 


Bild 4.14: Grafikzeichensätze 

Man sieht, daß nur die Texte mit der eingebauten Fontgröße gut aussehen. Die übrigen Grö¬ 
ßen werden aus diesen durch Umrechnen erzeugt, dadurch entstehen bei ungünstigen Ver¬ 
hältnissen zuweilen deutliche Verzerrungen. Dummerweise »hängt« sich der Atari bei den ab¬ 
soluten Texthöhen 12 und 26 auf. Gerade diese Werte würden keine Verzerrungen erwarten 
lassen, da sie ein Vielfaches der Systemfont-Größen darstellen! Die »Absolute Höhe« 12 ist die 
Verdopplung des 8x8 Fonts, 26 die des 8x16 Fonts. 
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Mit dem nachfolgendem kleinen Programm können Sie sich die Zeichensätze näher ansehen: 


MODULE GrafikZeichenSaetze; 


PROM Terminal IMPORT KeyPressed; 

PROM Strings IMPORT String, Append; 

PROM StrConv IMPORT CardToStr; 

PROM GrafBase IMPORT Pnt; 

PROM VDIOutputs IMPORT GrafText; 

PROM VDIAttributes IMPORT SetAbsTHeight; 

PROM Grafik IMPORT Geraet, anmelden, abmelden, SetzeBereich; 


VAR 

AbsHoehe, ChWeite, ChHoehe, ZeWeite, ZeHoehe 
s, sl, s2,s3,s4,s5 

y 

ok 

BEGIN 

anmelden; 

SetzeBereich(0,0,639, 399); 
y:=10; AbsHoehe: =4; 

REPEAT 

SetAbsTHeight(Geraet,AbsHoehe,ChWeite, ChHoehe, ZeWeite,ZeHoehe); 
s: =”Zeichensatz AbsH: ”; sl:=CardToStr(AbsHoehe, 2); 
s2: =CardToStr(ChWeite,2); s3:=CardToStr(ChHoehe, 2); 

Append(sl,s,ok); Append( , > v ,s,ok); Append(s3,s,ok); 

Append(’ * ’ ,s,ok); Append(s2,s, ok); 

INC(y, AbsHoehe+ 3); 

GrafText(Geraet,Pnt(10, y), s); 

INC(AbsHoehe); 

IP AbsHoehe=12 THEN INC(AbsHoehe) END (* Abshoehe 12 führt bei ...*) 
UNTIL AbsHoehe = 26; (* Megamax-Mod. zum Absturz *) 

REPEAT UNTIL KeyPressed(); 
abmelden 

END GrafikZeichenSaetze. 


: CARDINAL; 
: String; 

: INTEGER; 

: BOOLEAN; 


4.6.4 Ein externer Modul für VDI-Grafik 

Bei den folgenden Beispielen geht es um grafische Darstellung von Szenarien, die auf reellen 
Werten basieren (also nicht in handlichen Pixel-Koordinaten in INTEGER). Dabei tritt das 
Problem auf, daß die reellen Koordinaten, im folgenden »Weltkoordinaten« genannt, in 
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Pixelkoordinaten (»Bildkoordinaten«) umgerechnet werden müssen. Dieses Problem trat 
schon bei dem Mandelbrot-Programm auf. Diese Rechnerei versteckt man am besten in einem 
externen Modul »Graf ikWelt«. Dadurch werden nun die folgenden Programme sehr hand¬ 
lich. 

Dieser Modul baut auf unserem Modul Grafik auf und enthält neben den Routinen zur 
Konvertierung der Weltkoordinaten in Bildkoordinaten einige Prozeduren zum direkten 
Zeichnen mit Weltkoordinaten. Zu erwähnen ist auch die leistungsfähige Routine Achsen- 
Kreuz, die eine vollständige Skalierung und Beschriftung eines Achsenkreuzes übernimmt. 
Graphen sehen damit gleich erheblich besser aus. 

Ein Anwenderprogramm kann wie gewohnt SetzeBereich aus Grafik aufrufen. Dann 
teilt es dem Modul Graf ikWelt über SetzeSkalierung den Bereich der Weltkoordinaten 
mit, die es auf den Arbeitsbereich abgebildet haben will: 


MODULE EinGrafikModul; 

IMPORT Grafik, GrafikWelt; 

<■...> 

BEGIN (*- Haupt programm -*) 

Grafik.anmelden; 

Grafik.Hintergrund; 

Grafik. SetzeBereich(<....>); (* hier Pixelkoordinaten *) 

GrafikWelt. SetzeSkalierung(<....>); (* hier Weltkoordinalten *) 

GrafikWelt. Achsenkreuz (<....>); 

<Anwender-Anweisungen> 

Grafik, abmelden 
END EinGrafikModul. 

DEFINITION MODULE GrafikWelt; 

(* 

* Dient zur Bearbeitung von Grafiken in Koordinatensystemen. 

* Sämtliche zu übergebende Koordinaten sind ”Weltkoordinaten”, 

* d.h. sie entsprechen realen Größen, die von den Prozeduren 

* dieses Moduls in Bildschirmkoordinaten umgerechnet werden. 

* Vor der Benutzung ist ”anmelden” und ^SetzeBereich” aus dem 

* Modul ”Grafik” aufzurufen, am Ende ”abmelden”. *) 

FROM GrafBase IMPORT Point; 

(* ============ Initialisierungsprozedur ============= *) 

PROCEDURE SetzeSkalierung(xl,yl, x2, y2: REAL); 

(* 

* Berechnet die Skalierungsfaktoren für die Grafik. 
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* Dabei ist (xl,x2) die äußerste Weltkoordinate links unten 

* und (x2,y2) rechts oben. 

*) 

(* = = = = = = = = = = = = = = Maßstabskonvertierung = = = = = = = = = = = = = = *) 

PROCEDURE KonvertX(xW: REAL) : INTEGER; 

(* 

* Konvertiert die x-Weltkoordinate in die x-Bildschirmkoordinate. 

*) 

PROCEDURE KonvertY(yW:REAL) : INTEGER; 

(* 

* Konvertiert die y-Weltkoordinate in die y-Bildschirmkoordinate. 

*) 

PROCEDURE KonvertP(xW,yW : REAL) : Point; 

(* 

* Konvertiert den Weltpunkt (xW,yW) in den entsprechenden Bildpunkt. 
*) 

PROCEDURE KonvertLx(xAbst : REAL) : INTEGER; 

(* 

* Konvertiert den x-Abstand der ”Welt” in den des Bildschirms. 

*) 

PROCEDURE KonvertLy(yAbst : REAL) : INTEGER; 

(* 

* Konvertiert den y-Abstand der ”Welt” in den des Bildschirms. 

*) 

(* =============== Zeichen Prozeduren ================ *) 

PROCEDURE PlotW(xW,yW: REAL); 

(* 

* Zeichnet den dem Weltpunkt (xW,yW) entsprechenden Bildpunkt. 

*) 

PROCEDURE LineW(xl,yl, x2,y2: REAL); 

(* 

* Zeichnet eine Linie von (xl,yl) nach (x2,y2) (Weltkoordinaten). 

*) 

(* ================== Verschiedenes ================= *) 
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PROCEDURE HoleMausW(VAR xW,yW : REAL); 

C* 

* Diese Prozedur wartet auf das Klicken der 

* linken Maustaste. Sie übergibt dann die 

* dem Mauscursor entsprechenden Bildschirm- 

* koordinaten umgerechnet in Weltkoordinaten xW,yW. 

*) 

PROCEDURE AchsenKreuz(xEinheit, yEinheit : REAL; 

xDezimalen, yDezimalen : CARDINAL; 
xAchsenText, yAchsenText : ARRAY OP CHAR); 

(* 

* Zeichnet ein Achsenkreuz mit der Skala "xEinheit” 

* auf der x-Achse in Weltkoordinaten, entsprechend 

* ”y-Einheit”. Die Beschriftung der Skalen erfolgt 

* mit dezimalen Nachkommastellen. Die beiden Achsen 

* werden mit den Texten ”xAchsenText” bzw. 

* ^yAchsenText” versehen. Die Routine 

* prüft selbständig, wo genug Platz für die Beschrif- 

* tungen ist. Sind die ersten Parameter = 0.0, so 

* wird die Skala unterdrückt. Die Beschriftung wird 

* mit leeren Strings unterdrückt. 

*) 

END GrafikWelt. 


Die Implementation der Routine Achsenkreuz sieht relativ aufwendig aus. Sie muß aber 
automatisch viele ungünstige Fälle berücksichtigen, denn auch wenn die Achsen nahe am 
Bildschirmrand liegen, muß ein geeigneter Platz für die Beschriftung gefunden werden. An¬ 
fangs sollten Sie die Implementation ohnehin übergehen und gleich zu den Anwendungen wei¬ 
terblättern. 


IMPLEMENTATION MODULE GrafikWelt; 


PROM MathLibO IMPORT entier; 

PROM Strings IMPORT Length,String; 

PROM StrConv IMPORT RealToStr; 

PROM GrafBase IMPORT Point, Pnt; 

PROM GEMGlobals IMPORT MarkerType, LineType; 

PROM VDIOutputs IMPORT PillRectangle, Line, Mark; 

PROM VDIAttributes IMPORT SetMarkerType, SetLineType, SetLineColor; 

PROM VDIInputs IMPORT HideCursor, ShowCursor; 

PROM Grafik IMPORT Geraet, ArbeitsBereich, HoleMaus, Schreibe; 
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VAR 

GrafParm : RECORD 

xBMin, yBMin, xBMax, yBMax : INTEGER; (* Bildschirmausmaße *) 

xWMin, yWMin, xWMax, yWMax : REAL; (* »Welt”- Außmaße *) 

masstabX, masstabY : REAL (* Umrechnungsfaktoren*) 

END; 

PROCEDURE SetzeSkalierung(xl,yl, x2, y2: REAL); 

BEGIN 

WITH GrafParm DO 

WITH ArbeitsBereich DO 

xBMin:= xMin; yBMin:=yMin; xBMax:=xMax; yBMax:=yMax 
END; 

xWMin:=xl; yWMin := yl; xWMax := x2; yWMax : = y2; 
masstabX := FLOAT(xBMax - xBMin + 1) / (xWMax - xWMin); 

masstabY := PLOAT(yBMax - yBMin + 1) / (yWMax - yWMin); 

END; 

(* - Eine Voreinstellung.... (paßt hier ganz gut) - *) 

SetMarkerType(Geraet, pointMark); (* für ’PlotW’ *) 

END SetzeSkalierung; 

PROCEDURE KonvertX(xW:REAL) : INTEGER; 

BEGIN 

WITH GrafParm DO 

RETURN xBMin + SHORT(entier(masstabX * (xW-xWMin))) 

END 

END KonvertX; 

PROCEDURE KonvertY(yW: REAL) : INTEGER; 

BEGIN 

WITH GrafParm DO 

RETURN yBMax - SHORT(entier(masstabY * (yW-yWMin))) 

END 

END KonvertY; 

PROCEDURE KonvertP(xW,yW : REAL) : Point; 

BEGIN 

RETURN Pnt(KonvertX(xW), KonvertY(yW)) 

END KonvertP; 

PROCEDURE KonvertLx(xAbst : REAL) : INTEGER; 

BEGIN 

RETURN SHORT(entier(GrafParm.masstabX * xAbst)) 

END KonvertLx; 
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PROCEDURE Konve rtLy(yAbst : REAL) : INTEGER; 

BEGIN 

RETURN SHORT(entier(GrafParm.masstabY * yAbst)) 
END KonvertLy; 

PROCEDURE PlotW(xW,yW: REAL); 

BEGIN 

Mark(Geraet, KonvertP(xW,yW)) 

END PlotW; 

PROCEDURE LineW(xl,yl, x2,y2: REAL); 

BEGIN 

Line(Geraet, KonvertP(xl,yl), KonvertP(x2,y2)); 
END LineW; 

PROCEDURE HoleMausW(VAR xW,yW : REAL); 

VAR 

x,y: INTEGER; 

BEGIN 

HoleMaus(x,y); 

WITH GrafParm DO 


xW := xWMin 

+ FLOAT(x-xBMin) 

/ masstabX; 



yW := yWMin 

+ FLOAT(yBMax-y) 

/ masstabY 



END 





END HoleMausW; 





PROCEDURE AchsenKreuz(xEinheit, 

yEinheit 

: REAL; 



xDezimalen , 

yDezimalen 

: CARDINAL; 



xAchsenText, 

yAchsenText 

: ARRAY OF CHAR); 


CONST 





dsx = 4; dsy = 

; 4; 

( 

* Strichlängen für die Skalen 

*) 

VAR 





OrgX, OrgY : 

INTEGER; 

(* 

Nullpunkt in Bildkoordinaten 

*) 

justX, justY : 

INTEGER; 

(* 

Zur Textjustierung 

*) 

e : 

REAL; 




s : 

String; 





PROCEDURE XAchseSkalieren; 

BEGIN 

WITH GrafParm DO 

justY := OrgY + 7 + dsy; (* Zahlen unter die Achse *) 

IF justY > yBMax THEN justY := OrgY - dsy -1 END; (* unten kein Platz *) 
e := xEinheit; (* pos. x-Achse skalieren *) 
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WHILE e < xWMax DO 

Line(Geraet, Pnt(KonvertX(e),OrgY+dsy), 
s : = RealToStr(e, 0, xDezimalen); 

Schreibe(KonvertX(e)-INTEGER((Length(s) 
e := e + xEinheit 
END; 

e := - xEinheit; 

WHILE e > xWMin DO 

Line(Geraet, Pnt(KonvertX(e), OrgY+dsy), 
s := RealToStr(e,0,xDezimalen); 

Schreibe(KonvertX(e)-INTEGER((Length(s) 
e := e - xEinheit 
END 
END 

END XAchseSkalieren; 

PROCEDURE YAchseSkalieren; 

VAR laenge : CARDINAL; (* Maximallänge für die Skalenbeschriftung *) 

BEGIN 

WITH GrafParm DO 

e yEinheit; (* größte Zahlenlänge auf der pos. Achse ermittelen *) 
laenge:=0; 

WHILE e < yWMax DO 

s: - RealToStr(e,0,yDezimalen); 

IP laenge < Length(s) THEN laenge:=Length(s) END; 
e:=e + yEinheit; 

END; 

e := -yEinheit; (* gibt es auf der neg. Achse größere Werte ? *) 

WHILE e > yWMin DO 

s: =RealToStr(e,0,yDezimalen); 

IP laenge < Length(s) THEN laenge:=Length(s) END; 
e := e - yEinheit; 

END; 

justX :s OrgX - INTEGER(laenge)*6-dsx-2; (* Zahlen links an d. Achse *) 

IP justX < xBMin THEN justX:= OrgX + dsx +2 END; (* links kein Platz *) 
e := yEinheit; (* pos. y-Achse skalieren *) 

WHILE e < yWMax DO 

Line(Geraet, Pnt(OrgX+dsx,KonvertY(e)), Pnt(0rgX- dsx,KonvertY(e))); 
s :« RealToStr(e,0,yDezimalen); 

Schreibe(justX, KonvertY(e),1, s); 
e := e + yEinheit 
END; 

e := -yEinheit; (* neg. Achse skalieren *) 

WHILE e > yWMin DO 


Pnt(KonvertX(e),OrgY-dsy)); 

DIV 2))*6, justY,1, s); 

(* neg. x-Achse skalieren *) 
Pnt(KonvertX(e), OrgY-dsy)); 

DIV 2))*6, justY,1, s); 
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Line(Geraet, Pnt(OrgX+dsx,KonvertY(e)), Pnt(OrgX- dsx, KonvertY(e))); 
s := RealToStr(e,0,yDezimalen); 

SchreibetjustX, KonvertY(e), 1, s); 
e := e - yEinheit 
END 
END 

END YAchseSkalieren; 

PROCEDURE XAchseBeschriften; 

BEGIN 

WITH GrafParm DO 

justY := OrgY + 21 + dsy; (* Text unter die Achse *) 

IE justY > yBMax THEN justY := OrgY - dsy - 8 END;(* unten kein Platz *) 
justX := xBMax - 8*INTEGER(Length(xAchsenText)) - 2*dsx; 

Schreibe(justX, justY, 3, xAchsenText) 

END 

END XAchseBeschriften; 

PROCEDURE YAchseBeschriften; 

BEGIN 

WITH GrafParm DO 

justX : = OrgX - 8«• INTEGER(Length(yAchsenText)) - dsx; (* Text links *) 

IE justX < xBMin THEN justX := OrgX + dsx END; (* links kein Platz *) 

Schreibe(justX, yBMin+20,3,yAchsenText) 

END 

END YAchseBeschriften; 

BEGIN 

SetLineType(Geraet,solidLn); 

HideCursor(Geraet); 

WITH GrafParm DO 

OrgX := KonvertX(0.0); (* Nullpunkt ermitteln *) 

OrgY := KonvertY(0.0); 

IE (OrgX < xBMin) OR (xBMax < OrgX) THEN OrgX := xBMin END; 

IE (OrgY < yBMin) OR (yBMax < OrgY) THEN OrgY := yBMax END; 

IE (xWMin <= 0.0) & (0.0 <= xWMax) THEN 

Line(Geraet, Pnt(xBMin,OrgY), Pnt(xBMax,OrgY)); (* x-Achsezeichnen *) 

IE xEinheit >0.0 THEN XAchseSkalieren END; 

XAchseBeschriften 

END; 

IE (yWMin <= 0.0) AND (0.0 <= yWMax) THEN 

Line(Geraet, Pnt(OrgX,yBMin), Pnt(OrgX,yBMax)); (* y-Achsezeichnen *) 

IE yEinheit >0.0 THEN YAchseSkalieren END; 

YAchseBeschriften 
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END; 

END; 

ShowCursor(Geraet,PALSE); 

END AchsenKreuz; 

END GrafikWelt. 

Die beiden nächsten Beispiele sind etwas komplexer: Es geht um Simulationen aus der Biolo¬ 
gie und der Physik. Wir stellen jeweils die mathematischen Grundlagen zu den Programmen 
dar. Wenn Sie keine Mathematik mögen, überschlagen Sie diese Abschnitte einfach. Sie sind 
für das Verständnis der weiteren Abschnitte unwesentlich. 


4.6.5 Der Kampf ums Dasein 

Auf einer Insel mit üppiger Vegetation leben Füchse und Kaninchen. Die Kaninchen ernähren 
sich von dem Gras und die Füchse von den Kaninchen. Nun passiert folgendes: Wenn zu viele 
Füchse da sind, werden die Kaninchen rasch dezimiert. Das führt dazu, daß die Füchse kaum 
noch Nahrung finden, und sie fangen an, selbst einzugehen. Durch das Verschwinden der 
Füchse können sich aber die paar Kaninchen, die noch übrig sind, wieder ungestört vermeh¬ 
ren. Und auf einmal ist dann wieder Nahrung für die Füchse da... 

Im mathematischem Modell sieht das folgendermaßen aus: Zu einer Zeit t leben K (t) Ka¬ 
ninchen auf der Insel. Wenn wir die Füchse erst einmal weglassen, würden sich die Kaninchen 
innerhalb eines Zeitintervalls At vermehren. Der Zuwachs der Kaninchen AK wird propor¬ 
tional zu ihrer Anzahl und der Länge des Zeitintervalls At sein, also 

Ak ~ K*At, daraus folgt: 

AK = a*K*At 

wobei a Proportionalitätsfaktor ist (etwa »Geburtenrate«). Hiermit folgt: 

(I) K(t+At) = K(t) + a*K(t)*At 

Betrachten wir nun die Füchse. Gäbe es keine Kaninchen, so wird deren Anzahl F( t) ab¬ 
nehmen, da sie allmählich verhungern müßten: 

(II) F(t+At) = F(t) - c*F(t)*At 

Den Proportionalitätsfaktor c könnte man mit »Sterberate« bezeichnen. Nun leben aber 
Füchse und Kaninchen zusammen und das nicht gerade friedlich. Jede Begegnung von Füch- 
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sen und Kaninchen dezimiert die Kaninchen (werden gefressen), läßt aber die Zahl der Füchse 
steigen (weil sie dadurch satt werden). Die Anzahl der Begegnungen sind aber proportional 
zur Anzahl der Kaninchen K (t), zur Anzahl der Füchse F (t) und natürlich zur Länge des 
betrachteten Zeitintervalls At. Wir modifizieren also (I) und (II): 

(P) K(t + At) = K(t) + a*K(t)*At - b*K(t)*F(t) *At 
= K(t)*(1 + (a - b*F( t))*At) 

(II’)F(t + At) = F(t) - c*F( t)*At + d*K(t)*F(t)*At 
= F(t )*( 1 - (c - d*K(t))*At) 

Erstaunlich ist nun, daß sich die Kaninchen- und Fuchspopulation aufgrund von fressen und 
gefressen werden periodisch entwickeln. Das Ganze ist keine Spielerei, sondern man entdeckte 
die Periodizität in der Natur und konnte sie zunächst nicht erklären. Es wurden sogar (mal 
wieder) die Sonnenflecken dafür verantwortlich gemacht. Aber dahinter steckt mathematisch 
eine sogenannte »gekoppelte Differentialgleichung«, die nach den Mathematikern Voltera 
und Lotka benannt ist. Das folgende Programm gibt Aufschluß. Es zeigt die Kurven K(t) 
und F(t) für die Anfangswerte K(0)=30000 und F(0)=1500. Die Konstanten a, b, c, d 
wurden empirisch ermittelt. Die Rechnung ergibt eine Periodizität von 3,7 Jahren, in der Na¬ 
tur sind es 4 Jahre, da durch den Winter einige Unregelmäßigkeiten mit ins Spiel kommen. 

MODULE KampfUrasDaseinl; 

FROM Terminal IMPORT KeyPressed; 

FROM MathLibO IMPORT entier; 

FROM VDIInputs IMPORT HideCursor, ShowCursor; 

FROM Grafik IMPORT anmelden, abmelden, Geraet, 

Hintergrund, SetzeBereich ,Schreibe; 

FROM GrafikWelt IMPORT SetzeSkalierung, PlotW, AchsenKreuz; 

FROM GEMGlobals IMPORT GemChar; 

FROM AESEvents IMPORT KeyboardEvent; 

CONST 

a = 3.86; (* a,b,c,d empirisch gefundene ... *) 

b = 0.00177; (* ...Konstanten für die Population *) 

c = 0.823; 
d = 0.0000338; 
dt = 0.001; 

MaxJahre = 10. 0; 

VAR 


K,Kl,F,t: REAL; 
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PROCEDURE rechnen; 

BEGIN 

t : = 0. 0; 

HideCursor(Geraet); (* Maus beim Zeichnen wegmachen... *) 

REPEAT 
Kl: = K; 

K : = K + ( a * K - b * K * E) * dt; 

F : = F + (-c * F + d * Kl * F) * dt; 
t : = t + dt; 

PlotW(t, K); 

PlotW(t, F); 

UNTIL (MaxJahre < t) OR KeyPressed(); 

ShowCursor (Geraet, FALSE) (* Maus zeigen (muß ja da sein...) #) 

END rechnen; 

VAR taste: GemChar; 

BEGIN 

anmelden; 

Hintergrund; 

SetzeBereich(9, 9, 630,390); 

SetzeSkalierung(-1.0, -5000.0, MaxJahre, 60000.0); 

AchsenKreuz(l.0, 10000.0, 1,0, ”t/Jahre”, ”K, F”); 

Schreibe(150,50,4,”Fuchs-Kaninchen-Problem”); 

K : = 30000.0; 

F : = 1500.0; 
rechnen; 

KeyboardEvent(taste); 
abmelden 

END KampfUmsDaseinl. 


Noch überraschender als die Darstellung der Kurven K( t) und F( t) über der Zeit t ist die 
Darstellung von F über K. Ihr liegt die Fragestellung zu Grunde: Wieviele Füchse gibt es bei 
einer bestimmten Kaninchenzahl? Man erhält eine geschlossene Kurve. Damit man verschie¬ 
dene Anfangswerte K (0) und F (0) bequem ausprobieren kann, setzen wir die Maus ein: Be¬ 
liebige Werte K und F werden durch Anklicken auf dem Bildschirm an der entsprechenden 
Position eingegeben. Intern werden die Werte durch die Prozedur Anklicken von der Maus 
gelesen und direkt in die richtigen Werte (»Weltkoordinaten«) umgerechnet. Wenn man meh¬ 
rere verschiedene Punkte für die Kaninchen und Füchse angibt, erhält man verschiedene ge¬ 
schlossene Kurven, die einen gemeinsamen Mittelpunkt haben, den Gleichgewichtspunkt (er 
liegt bei K = 24350 und F = 2180 . Das kann man direkt den Gleichungen (P ) und 
(II* ) entnehmen; die Klammerausdrücke müssen dabei l ergeben). 
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Bild 4.15: Das Fuchs-Kaninchen-Problem 


MODULE KampfUmsDasein2; 

FROM Terminal IMPORT BusyRead; 

FROM AESForms IMPORT FormAlert; 

FROM VDIInputs IMPORT ShowCursor, HideCursor; 

FROM Grafik IMPORT anmelden, abmelden, Geraet, Hintergrund, SetzeBereich; 

FROM GrafikWelt IMPORT SetzeSkalierung, PlotW, AchsenKreuz, HoleMausW; 


CONST a = 3.86; 

b = 0.00177; 
c = 0.823; 
d = 0.0000338; 
dt = 0.001; 
xH = 639; 
yH = 399; 


(■» Bedeutung der Werte s. KampfUmsDaseinl *) 


VAR 


K,Kl,F,t: REAL; 
ch : CHAR; 
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PROCEDURE BedienungsAnleitung; 

VAR s : ARRAY [0..80] OF CHAR; 

AntwortKnopf : CARDINAL; 

BEGIN 

s: =”[3][Mausklick setzt Anfangswerte| |Taste unterbricht! (ESC = Ende][0k]”; 
FormAlert(1,s,AntwortKnopf) 

END BedienungsAnleitung; 

PROCEDURE rechnen; 

BEGIN 

t : = 0.0; 

HideCursor(Geraet); 

REPEAT 
Kl : = K; 

K:=K+(a*K-b*K * F) * dt; 

F : = F + (-c * F + d * Kl * F) * dt; 
t : = t + dt; 

PlotW(K,F); 

BusyRead(ch); 

UNTIL ch # OC; 

ShowCursor(Geraet,FALSE); 

END rechnen; 

BEGIN 

anmelden; 

Hintergrund; 

BedienungsAnleitung; 

SetzeBereich(10,10, xH-10,yH-10); 

SetzeSkalierung(-7000. 0,-400. 0, 70000.0, 4000.0); 

AchsenKreuz(10000.0, 500.0,0,0, "Kaninchen”, "Füchse”); 

REPEAT 

HoleMausW(K,F); 
rechnen; 

UNTIL ch = 33C; (* ESC: Fertig *) 

abmelden 

END KampfUmsDaseinÄ. 
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Bild 4.16: Darstellung der Fuchszahl über der Kaninchenzahl 


4.6.6 Kepler, Newton und Atari 

Das zweite Beispiel ist von den Berechnungen her noch etwas interessanter. Es stellt die Bah¬ 
nen von Satelliten dar, die zum Beispiel in 35875 km über dem Äquator tangential von einer 
Rakete mit den Anfangsgeschwindigkeiten 3.071 km/s, 3.8 km/s und 4.8 km/s abgeschossen 
wurden. Der erste Wert entspricht der Geschwindigkeit eines »Synchronsatelliten« der sich 
auf einer Kreisbahn mit der Umlaufszeit 24 Stunden bewegt, also scheinbar fest über einem 
Ort der Erde steht (Fernsehsatellit). Mit der zweiten Geschwindigkeit erhält man eine Ellip¬ 
senbahn, mit der dritten eine Hyperbelbahn. 
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Satelliten l 

Y 


Starthöhe in kn: 
35857 

vx in kn/s: 

B 

vy in kn/s: 

3,871 

Starthöhe in kn: 
35857 

vx in kn/s: 

60000 . 

40000 ' _ 

S0000 _ 

0 

n i-1 i i-1-1-^-1 i 

-140000 -120000 -10000O -80000 -60000 -40000 -20000 20000 40000 

vy in kn/s: 


X 

3.8 




-20000 - 


Starthöhe in kn: 



35857 



vx in kn/s: 

-40000 _ 


0 



vy in kn/s: 

-60000. 


4 1 8 




Bild 4.17: Drei Satellitenbahnen 

Wir erläutern den Algorithmus für die Bahnkurve. Die Erklärungen sind hier etwas breiter, 
dafür lassen sie sich auf andere Beispiele übertragen. Auch diesen Abschnitt können Sie ge¬ 
trost übergehen, wenn Sie sich nicht mit den mathematischen und physikalischen Grundlagen 
herumschlagen möchten. 

Da die Bewegung in der Ebene, die vom Erdmittelpunkt und der Kurve des Satellitenmittel¬ 
punktes aufgespannt wird, genügen zwei Koordinaten x und y zur Darstellung des Satelli¬ 
ten. Mittelpunkt des Koordinatensystems ist der Erdmittelpunkt. 

Mit v x , v y seien die Komponenten des Geschwindigkeitsvektorsv genannt, analog mit a x , a y 
die des Beschleunigungsvektors a. Aus der Mechanik brauchen wir nun die Formeln: 

(i) F = m-a (Kraft = Masse Beschleunigung) 

(ii) a= lim v ■ t ^ t — v ^ - (Beschl. = Geschwindigkeitsänderungen pro Zeit At) 

At-o At 

—y —► 

(iii) v= lim s Ü +At ) ~ s (Geschwindigkeit = Wegänderung pro Zeit At) 

At-o At 
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Die Gleichungen (i)-(iii) beschreiben nun ein Prinzip, daß nicht nur bei diesem Beispiel gilt. 
Vielmehr dient es allgemein dazu, die Bahn eines Körpers zu berechnen: Aus der jeweils herr¬ 
schenden Kraft errechnet man mittels (i) die Beschleunigung, aus dieser dann mit (ii) die neue 
Geschwindigkeit nach der Zeitspanne At und hieraus mit (iii) letztlich den neuen Ort. Hierzu 
muß lediglich noch der anfängliche Ort s(0) und die Anfangsgeschwindigkeit v(0) bekannt 
sein. Natürlich können wir nicht die Grenzwertbildung von (ii) und (iii) mit dem Rechner 
durchführen. Ist aber das betrachtete Zeitintervall hinreichend kurz, so folgt aus (i) und (ii) 
näherungsweise: 

(ii’) v (t +At) = v(t) +a- At 
(iii’) s(t +At) = "s(t) +v* At 

d. h. die Geschwindigkeit und der Ort läßt sich am Intervallende durch die Kenntnis ihrer 
Werte am Inervallanfang bestimmen. Man kann also »in die Zukunft sehen«! 

Schreiben wir (ii’) und (iii’) noch komponentenweise, so folgt 

(ii’) v x (t +At) = v x (t) +a x -At und v y (t +At) = v y (t) +a y -At 

(iii’)s x (t +At) = s x (t) +v x -At und s y (t +At) = s y (t) +v y -At 

Nun fehlt nur noch die computergerechte Aufbereitung der Formel (i). Wir stellen hier nach 
ä"um und erhalten komponentenweise geschrieben: 

(i’) a x = — F x und a v = — F v 

v/x m x y m y 

Fehlt nur noch das Kraftgesetz! Newton hat es herausgefunden, als er unter einem Apfelbaum 
lag und herunterfallende Früchte betrachtete: 

(iv ) F =_ f J^L_ 

r l 

Dabei ist m E die Erdmasse, m die des Satelliten, r der Abstand Erdmittelpunkt zu Satellit und f 
eine Konstante, die sogenannte Gravitationskonstante. Das Minuszeichen rührt daher, daß 
es sich um eine anziehende Kraft handelt (vgl. Abb). 
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Bild 4.18: Gravitationskraft zwischen Erde und Satellit 

Aus der Ähnlichkeit der Dreiecke ABC und DEC ergibt sich nun für die Kraftkomponenten 
F x und F y : 


(vi) F x = - -f x 

und 

F = - —-y 

r y r y 


also folgt insgesamt: 




(i”) a x = -fm E 

r - 3 

und 

a y = -fm E 



Den Abstand r erhält man nach dem Satz des Pythagoras zu r = x /x 2 +y 2 . 


Programmiert man nun die Gleichungen (in’), (i”) und (ii”) hintereinander, so erhält man die 
gesuchten Bahnkurven, die schon Kepler beschrieb. 

Es ergibt sich jedoch eine größere Abweichung von der tatsächlichen Satellitenbahn (von der 
Erde weg), da die Beschleunigung und hieraus die neue Geschwindigkeit stets mit den Werten 
vom Intervallanfang ermittelt werden. Während der Zeitspanne At ändern sich aber diese 
Werte. Eine Möglichkeit ist es, At sehr klein zu wählen (zum Beispiel eine Sekunde), was aber 
die Rechenzeit erhöht. Besser geht es mit folgendem Trick, dem »Halbschrittverfahren«: 

Einmal zu Beginn ermittelt man die Geschwindigkeit in der Intervallmitte (also zur Zeit 
At/2), errechnet daraus den Ort und die Beschleunigung zur Zeit A t, dann daraus wiederum 
die Geschwindigkeit bei At + At/2 usw. Die einmalige Vorwegberechnung ist unaufwendig, er¬ 
höht die Genauigkeit aber erheblich, so daß wir mit einer Zeitspanne von At =15 Sekunden 
gute Werte erhalten. 
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MODULE SatellitenBahnen; 


PROM GrafBase IMPORT 
PROM GEMGlobals IMPORT 
PROM VDIOutputs IMPORT 
PROM VDIAttributes IMPORT 
PROM VDIInputs IMPORT 
PROM AESPorms IMPORT 
PROM TextWindows IMPORT 


PROM MathLibO IMPORT 
PROM StrConv IMPORT 
PROM Sound IMPORT 
PROM Grafik IMPORT 
PROM GrafikWelt IMPORT 


black; 

MarkerType; 

Circle; 

SetPillColor; 

HideCursor, ShowCursor; 

PormAlert; 

Window,WindowQuality,PorceMode, KeyPressed, 

Open, Close, WQualitySet, ShowMode, 

ReadString, WriteString, WriteLn, WritePg; 
sqrt, entier; 

StrToReal; 

Einstellen, Ton, Aufhoeren; 

anmelden, abmelden, Geraet, Hintergrund, SetzeBereich; 
SetzeSkalierung, PlotW, 

AchsenKreuz, KonvertP, KonvertLx; 


CONST 


dt = 15.0; 
sec = 1200.0; 
me = 5.974E24; 
re = 6370.3; 
f =6.67E-20; 
k = -me*f*dt; 


(* Sekunden-Abstand zwischen 2 Berechnungen *) 
(* Abstand zwischen 2 Plots (= 20 Minuten) *) 
(* Erdmasse in kg *) 

(* mittlerer Erdradius in km *) 

(* Gravitationskonstante in knT3/(kg s~2) *) 

(* Konstante für die Beschleunigungen ax, ay *) 


VAR 


x, y, vx, vy, ax, ay 

radius 

hoehe 

t 

EingabePenster 
ok, abgestuertzt 


REAL 
REAL 
REAL 
REAL 
Window; 
BOOLEAN; 


(* Ort-, Geschw.-, Beschl. Koo. des Sat.*) 
(* Abstand Satellit - Erdmittelpunkt *) 
(* Anfangshöhe über der Erdoberfläche *) 
(* Zeit, wird zw. 2 Plots hochgezählt *) 


PROCEDURE InitBildschirm; 

VAR einheit,i : INTEGER; 

BEGIN 

SetzeBereich(150,10,630,390); 

SetzeSkalierung(-150000.0, -80000.0, 50000.0, 80000.0); 

AchsenKreuz(20000.0, 20000.0,0,0, ”X”, ”Y”); 

HideCursor(Geraet); 

SetPillColor(Geraet,black); 

Circle(Geraet, KonvertP(0.0, 0.0),KonvertLx(re)); (* Erde zeichnen *) 

ShowCursor(Geraet,PALSE) 
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END InitBildschirm; 

PROCEDURE Eingabe; 

PROCEDURE LiesReal(s : ARRAY OP CHAR) : REAL; 

VAR pos : CARDINAL; 

hilf : ARRAY[0..8] OP CHAR; 
ok : BOOLEAN; 

BEGIN 

WriteLn(EingabePenster); 

WriteString(EingabePenster,s); 

WriteLn(EingabePenster); 

ReadString(EingabePenster,hilf); 
pos:=0; 

RETURN StrToReal(hilf,pos,ok) 

END LiesReal; 

BEGIN 

WriteLn(EingabePenster); 

WriteString(EingabePenster,” -”); 

hoehe:=LiesReal(”Starthöhe in km:”); 
vx:=LiesReal(”vx in km/s:”); 
vy:=LiesReal(”vy in km/s:”) 

END Eingabe; 

PROCEDURE SatellitRechnen; 

VAR 

hilf, radHoch2, radHoch3 : REAL; 

BEGIN 

x: =re+hoehe; y:=0.0; t:=0.0; 

PlotW(x,y); 

(* -Vorweg-Halb schritt-*) 

radHoch2:=x*x+y*y; 
radius: =sqrt(radHoch2); 
radHoch3: =radHoch2*radius; 

hilf : =k/radHoch3/2.0; (* für die Beschl. in der Intervallmitte *) 

vx:=vx+x*hilf; 
vy:=vy+y*hilf; 

(* --Rechen-Schleife- *) 

HideCursor(Geraet); 

REPEAT 
t:=t+dt; 
x: =x+vx*dt; 
y:=y+vy*dt; 
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radHoch2: =x*x+y*y; 
radius:=sqrt(radHoch2); 
radHoch3:=radHoch2*radius; 
hilf:=k/radHoch3; 
vx:=vx+x*hilf; 
vy:=vy+y*hilf; 

IP t>=sec THEN PlotW(x,y); t:=t-sec END; 
abgestuertzt:=(radius < re); 

IF abgestuertzt THEN Einstellen(15); Ton(2400,50); Aufhoeren END; 

UNTIL abgestuertzt OR KeyPressed(); 

ShowCursor(Geraet,PALSE); 

END SatellitRechnen; 

PROCEDURE fertig : BOOLEAN; 

VAR knöpf : CARDINAL; 

s : ARRAY [0..80] OP CHAR; 

BEGIN 

ShowCursor(Geraet,PALSE); 

IP abgestuertzt THEN 

s:=»[l][Der Satellit ist abgestütztl |Was nun. . . ] [Eingabe|Löschen|Ende]” 
ELSE 

s: = »[3] [Was nun. . . ] [Eingabe|Löschen|Ende]» 

END; 

PormAlert(1,s,knöpf); 

IP knopf=2 THEN InitBildschirm; WritePg(EingabePenster); END; 

HideCursor(Geraet); 

RETURN knöpf=3 
END fertig; 

BEGIN 

anmelden; 

Hintergrund; 

InitBildschirm; 

Open(EingabePenster,80,25,WQualitySet{titled), noHideWdw, forceLine, 
»Satelliten»,1,1,17,24,ok); 

REPEAT 

Eingabe; 

SatellitRechnen; 

UNTIL fertig(); 

Close(EingabePenster); 
abmelden 

END SatellitenBahnen. 
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Falls Sie Gefallen an solchen physikalischen Simulationen gefunden haben, hier noch einige 
Anregungen, bei denen Sie in den obigen Gleichungen nur die jeweilige Kraftfunktion abzu¬ 
ändern brauchen: 

• Simulieren Sie die Bahn eines schnellen a -Teilchens, daß in die Nähe eines positiv gelade¬ 
nen Atomkerns gelangt. Man braucht dann nur die Konstanten und das Vorzeichen der 
Kraft im Programm zu ändern! 

• Simulieren Sie die Bahn eines Geschosses in der Luft oder trivialer einer Kugel beim Kugel¬ 
stoßen. Welches ist bei letzterer der optimale Abwurfswinkel (eben nicht 45° wie man es in 
der Schule lernt!). 

• Simulieren Sie die Bahn eines elektrisch geladenen Teilchen in speziellen elektrischen und 
magnetischen Feldern. Hierzu muß auch die z-Koordinate betrachtet werden. Implemen¬ 
tieren Sie eine 3-D-Darstellung! 

• Simulieren Sie einen Ball im Schwerefeld der Erde (an der Erdoberfläche gilt für die Kraft 
einfach F y =-g, F x = 0, (g = 9.81 m/s 2 )). Trifft der Ball auf den Boden, so wird er nach dem 
Reflexionsgesetz reflektiert (einfach vy = -vy setzen). Dies könnte schon in einem Spiel 
brauchbar sein. 


4.6.7 Auswertung von Meßreihen (lineare Regression) 

Den Abschluß dieses Grafikabschnittes bildet ein Programm, daß jeder brauchen kann, der es 
mit Messungen (in der Schule, im Labor) zu tun hat. Wir gehen von folgender Problemstellung 
aus: 

Gegeben sei ein Experiment, das n Wertepaare (x k , y k ) von Meßdaten liefert z.B.: 

x k || 0.0 | 0.2 | 0.4 | 0.5 | 0.8 | 1.0 | 1.5 | 1.8 | 
y k || 7.0 | 8.2 | 9.0 | 10.2 | 13.4 | 14.0 | 15.0 | 18. 2 | 

Die Meßdaten seien so gestaltet, daß man einen lineareren Zusammenhang y = mx+b ver¬ 
mutet, der Graph müßte also eine Gerade ergeben. Da man wegen Meßfehlern nicht erwarten 
kann, daß alle Meßwertepaare exakt auf einer Geraden liegen, ergibt sich die Frage nach der 
optimalen Geraden mit der Steigung m und dem Achsenabschnitt b, durch die die »Punkt¬ 
wolke« bestmöglich angenähert wird. Diese Gerade heißt Ausgleichsgerade. 

Dieses Problem wird nach Gauß mit der »Methode der kleinsten Fehlerquadrate« gelöst. 
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Ausg 


eichsgerade: y = 6.0162 * x + 7.2124 Bestinntheitsnaß: 0.956988 


Bild 4.19: Ausgleichsgerade zu einer Meßreihe 


Interessierte finden die zugehörige mathematische Herleitung im Anschluß an das Programm. 
Außer der Steigung und dem Achsenabschnitt der Ausgleichsgerade liefert das Programm ein 
Maß (»Bestimmtheitsmaß« r 2 ) dafür, wie »gut« die Meßpunkte auf einer Geraden liegen. Ist 
r 2 = 1 , so bedeutet dies, daß alle Punkte genau auf der Geraden liegen; umgekehrt ist für 
r 2 =0 auf einen nichtlinearen Zusammenhang zu schließen. Als »normaler« Wert für eine 
lineare Meßreihe darf r 2 =0, 9, als »guter« Wert r 2 =0, 99 gelten. 


MODUL! MessReihen; 


PROM MathLibO 
PROM Strings 
PROM StrConv 
PROM VDIInputs 
PROM VDIAttributes 
PROM GEMGlobals 
PROM AESEvents 
PROM Grafik 


IMPORT log, pwrOfTen, real, entier; (* für Pr. "Glaetten” *) 
IMPORT String, Append; 

IMPORT RealToStr; 

IMPORT HideCursor, ShowCursor; 

IMPORT SetMarkerType; 

IMPORT GemChar, MarkerType; 

IMPORT KeyboardEvent; 

IMPORT anmelden, abmelden, Geraet, 

Hintergrund, SetzeBereich »Schreibe; 

IMPORT SetzeSkalierung, PlotW, LineW, AchsenKreuz; 


PROM GrafikWelt 
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TYPE Messwert = RECORD 

x, y :REAL; 
END; 


VAR 

Werte 

Steigung, yAbschnitt, BMass 
xMax, yMax 
ok 


ARRAY [0..7] OF MessWert; 
REAL; 

REAL; 

BOOLEAN; 


PROCEDURE Eingabe; 
BEGIN 

Werte[0].x 
Werte[2].x 
Werte[4].x 
Werte{6].x 
END Eingabe; 


(* Test-Prozedur *) 


0. 0; Werte[0].y 
0. 4; Werte[2].y 
0.8; Werte[4].y 
1.5; Werte[6]. y 


: = 7.0; 

Werte[1].x 

:= 0.2; Werte [1 ]. y 

:= 8.2; 

: = 9. 0; 

Werte[3].x 

: = 0.5; Werte[3]. y 

: =10. 2; 

: =13. 4; 

Werte[5].x 

:= 1.0; Werte[5].y 

: =14.0; 

:=15.0; 

Werte[7].x 

:= 1.8; Werte[7J.y 

:=18.2; 


PROCEDURE Berechnen(VAR Messung 

VAR Anstieg, Abschnitt, BestimmtMass 
VAR xmax, ymax 
VAR Fehler 

VAR 

sx, sx2, sy, sy2, sxy, zaehler, nennerX, nennerY, anzahl : REAL; 
i : CARDINAL; 


ARRAY OF Messwert; 
REAL; 

REAL; 

BOOLEAN); 


nur pos. Messwerte *) 
.. sind zugelassen *) 


BEGIN 

Fehler := FALSE; 

IF HIGH(Messung) < 1 THEN Fehler:= TRUE; RETURN END; (* mind. 2 Meßwerte *) 
sx:=0.0; sy: =0. 0; sx2: =0. 0; sy2:=0.0; sxy:=0.0; xmax:=0.0; ymax:=0.0; 

FOR i:=0 TO HIGH(Messung) DO 
WITH Messung[i] DO 

Fehler := (x < 0.0) ; Fehler := (y < 0.0 ); (« 

IF Fehler THEN RETURN END; (« 

IF x > xmax THEN xmax:=x END; 

IF y > ymax THEN ymax:=y END; 
sx := sx + x; sy := sy + y; sxy:= sxy + x*y; 
sx2:= sx2 + x*x; sy2:= sy2 + y*y; 

END 
END; 

anzahl : = FL0AT(HIGH(Messung) + 1); 
zaehler := sxy - sx*sy/ anzahl; 
nennerX := sx2 - sx*sx/ anzahl; 
nennerY := sy2 - sy*sy/ anzahl; 
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IF nennerX*nennerY =0.0 THEN Fehler:=TRUE; RETURN END; (* nur gleiche . .*) 
Anstieg := zaehler / nennerX; (* ... Meßwerte *) 

Abschnitt := (sy-Anstieg*sx) / anzahl; 

BestimratMass := zaehler * zaehler / ( nennerX*nennerY); 

END Berechnen; 

PROCEDURE Ausgabe(VAR Messung 

VAR Anstieg, Abschnitt, BestimmtMass 
VAR xmax, ymax 
Fehler 

VAR 

i : CARDINAL; 

s,sl, s2, s3 : String; 

ok, Minus : BOOLEAN; 

taste : GemChar; 

PROCEDURE Glaetten (VAR zahl : REAL); (* Liefert glatte Werte für ... *) 

VAR (* ... die Achsenbeschriftungen *) 

expo,mantisse,zehner : REAL; 

Minus : BOOLEAN; 

BEGIN 

expo := log(zahl*l.1); 

IF expo <0.0 THEN expo := expo - 1.0 END; 
expo := real(entier(expo)); 
zehner := pwrOfTen(expo); 
mantisse := zahl/zehner; 


? mantisse <= 1. 

0 THEN 

mantisse := 1.0 


ELSIF 

mantisse 

<= 2.0 

THEN 

mantisse := 

2.0 

ELSIF 

mantisse 

<= 4.0 

THEN 

mantisse := 

4.0 

ELSIF 

mantisse 

<= 5.0 

THEN 

mantisse := 

5. 0 

ELSIF 

mantisse 

<= 6.0 

THEN 

mantisse := 

6.0 

ELSIF 

mantisse 

<= 8.0 

THEN 

mantisse := 

8. 0 

ELSE mantisse: = 

= 10.0 





END; 

zahl := mantisse*zehner 
END Glaetten; 

BEGIN 

anmelden; 

Hintergrund; 

SetzeBereich(9,9, 630,390); 

IF Fehler THEN 

Schreibe(10,210,3, 

"Fehlerhafte Eingabe: nur gleiche, negative oder weniger als 2 Meßwerte"); 


ARRAY OF Messwert; 
REAL; 

REAL; 

BOOLEAN); 




386 


Benutzung von VDI-Grafik-Routinen 


ELSE 

Glaetten(xmax); Glaetten(ymax); (* Grafikausgabe vorbereiten *) 

SetzeSkalierung(-xmax/10.0, -ymax/10.0, l.l*xmax, l.l*ymax); 

AchsenKreuz(xmax/10.0, ymax/10.0, 2, 2, ”X”, ”Y”); 

HideCursor(Geraet); 

SetMarkerType(Geraet,starMark); 

POH i: =0 TO HIGH(Messung) DO PlotW(Messung[i]. x, Messung[i].y) END; 
LineW(0.0, Abschnitt, xMax, Anstieg*xmax + Abschnitt); 

Minus := (Anstieg < 0.0); (* Textausgabe vorbereiten *) 

Anstieg := ABS(Anstieg); 

sl := RealToStr(Anstieg,0,4); 

s2 := RealToStr(Abschnitt,0,4); 

s3 : = RealToStr(BestimmtMass,0, 6); 

s := ”Ausgleichsgerade: y = ”; 

Append(sl,s,ok); Append(” * x ”,s,ok); 

IP Minus THEN Append(”- ”,s,ok) ELSE Append(”+ ”,s,ok) END; 

Append(s2,s,ok); 

Append(” Bestimmtheitsmaß: ”,s,ok); Append(s3,s,ok); 

Schreibe(25,385,2,s); 

ShowCursor(Geraet,PALSE); 

END; 

KeyboardEvent(taste); 
abmelden 
END Ausgabe; 

BEGIN 

Eingabe; 

Berechnen(Werte,Steigung, yAbschnitt, BMass, xMax, yMax, ok); 

Ausgabe(Werte,Steigung,yAbschnitt,BMass, xMax, yMax, ok); 

END MessReihen. 


Hier nun für Interessierte die mathematische Herleitung für die Steigung m und den Achsen¬ 
abschnitt b der Ausgleichsgeraden: 

Es sei (x k ,y k ) ein Wertepaar, dann beschreibt der Ausdruck y k - (m-x k + b) die Abweichung des 
k-ten Punktes von der Ausgleichsgeraden. Da diese Abweichung sowohl positiv als auch nega¬ 
tiv sein kann, betrachtet man als Maß für den Fehler f k der Einzelmessung das Quadrat dieser 
Abweichung. 

In der Summe 


F(m,b) = Z f k = Z (y k -(mx k +b)) 2 
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sind also m und b so zu bestimmen, daß die Summe minimal wird. Man sieht, daß F sowohl in 
m als auch in b eine quadratische Funktion ist. 

Wie sich mittels Differentialrechnung oder der Scheitelpunktform der Parabelgleichung er¬ 
gibt, hat eine quadratische Funktion 

q(z) = a, z 2 +a 2 -z+a 3 mit a, >0 

ihr Minimum an der Stelle 

Zmin= -a 2 /(2-a,). 

Nutzt man dies für F(m) und F(b) aus, so erhält man für die Steigung m und den Achsenab¬ 
schnitt b nach kurzer Rechnung die Beziehungen: 

_ Ex k y k -Sx k -£ Yk/n 

m 2 x k 2 -(£ x k ) 2 /n 
b= (2y k -m l x k ) / n 

wobei jeweils über alle n Wertepaare zu summieren ist. Als Maß dafür, wie gut die Gesamtheit 
der Punkte die Ausgleichsgerade annähert, benutzt man in der Statistik das sogenannte Be¬ 
stimmtheitsmaß r 2 : 

2 _ (S x k y k -£x k -2y k /n) 2 _ 

F (2x k 2 -(2x k ) 2 /n) (2y k 2 -(Xy k ) 2 /n) 

Die Theorie zeigt, daß für den Korrelationskoeffizienten r stets die folgenden Grenzen be¬ 
stehen: -1 ^r^ 1, also O^r 2 ^ 1. Liegen alle Punkte exakt auf einer Geraden, so folgt r 2 = 1, die 
Messung ist also um so weniger mit Fehlern behaftet, desto mehr sich r 2 an 1 angleicht. In der 
Prozedur Berechnen werden die obigen Terme für m, b und r 2 ermittelt. Außerdem wird 
noch der größte x-Wert und der größte y-Wert festgehalten für die Erstellung der Grafik. Da 
diese Werte eventuell sehr »krumm« sein können, werden sie in der Prozedur Glaetten auf 
einen »glatten« Wert aufgerundet (für die Einteilungen des Achsenkreuzes). Es wird ein¬ 
schränkend davon ausgegangen, daß alle Meßwerte positiv sind. Ansonsten sind die Prozedu¬ 
ren Berechnen und Ausgabe allgemein gehalten. Lediglich die Prozedur Eingabe ist nur 
rudimentär als Testprozedur ausgeführt. Es gibt hier je nach Verwendungszweck verschie¬ 
dene Eingabemöglichkeiten: 

• Wenn man nur gelegentlich Messungen kleinerer Versuchsreihen auswerten muß, genügt 
eine Eingabe der Daten über die Tastatur. Schreiben Sie sich eine redigierbare Eingabe¬ 
prozedur hierzu (Korrigieren und Hinzufügen von Wertepaaren, nachdem man die Grafik 
gerechnet hat). Die Techniken dazu wurden in Kapitel 1.7 gezeigt. 
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• Wenn viele Meßdaten anfallen, so wird man sie direkt von einem externen Gerät einiesen, 
zum Beispiel von einem Analog-/Digital-Wandler (A/D-Wandler). 

• Die Meßwerte liegen als (ASCII-)Text in einem File vor. Das Programm braucht nur das 
File einzulesen. Dies ist die übliche Methode bei großen Datenmengen! Die Lösung dieser 
Aufgabe finden Sie auf der Diskette. 

Neben einer Verbesserung der Eingabeprozedur sind auch noch folgende Erweiterungen 
denkbar: 


• Man läßt auch negative Werte zu. In diesem Fall muß auch der minimale x-Wert und der 
minimale y-Wert ermittelt werden. 

• Ausgabe eines Meßprotokolls auf den Drucker 

• Sortieren der Meßwerte (nach x oder y) 

Oft hat man Meßreihen, die keinen linearen Zusammenhang zwischen den Meßgrößen x und 
y nahelegen, zum Beispiel kann x antiproportional zu y sein (y=m/x+b ). 

Man kann dann das vorliegende Programm trotzdem nutzen, wenn man statt der Meßwerte 
x k einfach l/x k eingibt. Damit man nicht l/x zunächst mit einem Taschenrechner ermitteln 
muß, kann man dies dem Programm überlassen, indem man vor der Berechnung der Aus¬ 
gleichsgeraden durch ein Untermenü den vermuteten Zusammenhang erfragen läßt. 

In die Berechnungen für m, b, und r läßt man dann^nicht die Zahlen x k , sondern die Funk¬ 
tionswerte g ( x k ) mit g ( x ) = l/x eingehen. 

Für andere funktionale Beziehungen kann es auch nötig sein, die y-Werte mit einer Funktion 
h(y) zu verbiegen. Denkbar sind vor allem folgende Funktionen: 


1. Linearer Zusammenhang: 

2. Quadratischer Zusammenhang: 

3. Antiproportionaler Zusammenhang: 

4. Antiproportional-quadratischer Zus.: 

5. Exponentieller Zusammenhang: 

6. Potenzfunktionaler Zusammenhang: 


y 

= 

m 

x + b, 

y 

= 

m 

x 2 + b, 

y 

= 

m 

/ x + b, 

y 

= 

m 

/ x 2 + b 

y 

= 

k 

e mx , 

y 

= 

a 

xb 


Die Ausgabe der Ausgleichsfunktion ist auch entsprechend zu modifizieren. Anleitung: De¬ 
finieren Sie eine globale Variable art, die im Untermenü mit der Nummer des Zusammen¬ 
hangs 1 bis 6 belegt wird. Programmieren Sie nun die Funktionen 


PROCEDURE g(x: REAL): REAL; 
PROCEDURE h(x: REAL): REAL; 
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mit einer CASE-Anweisung je nach art. In der folgenden Tabelle sind die funktionalen Zu¬ 
sammenhänge wiedergegeben (SQR(x) ist dabei x*x): 


1. g(x) = x, h(x) = y 

2. g(x) = SQR(x), h(x) = y 

3. g(x) = 1/x, h(x) = y 

4. g(x) = l/SQR(x), h(x) = y 

5. g(x) = x, h(x) = LN(y) 

6. g(x) = LN(x), h(x) = LN(y) 


Besonders ergonomisch wäre es, wenn man die verschiedenen Funktionstypen sowie die 
Punkte Eingabe, Graphik, Druckerausgabe mit Pull-down-Menüs anwählen könnte. Wie 
man diese programmiert, erfahren Sie im nächsten Abschnitt. 


4.7 GEM-Menütechnik und Ereignisbehandlung 

Sicherlich ist es Ihnen aufgefallen, daß in professionellen Programmen auf dem Atari Pull- 
down-Menüs verwendet werden, die eine sehr übersichtliche Benutzerführung gestatten. 
Pull-down-Menüs werden vom AES automatisch verwaltet, was die Handhabung beim Pro¬ 
grammieren deutlich vereinfacht. AES verlangt allerdings, daß das Pull-down-Menü in einer 
besonderen Datenstruktur - einem »Objektbaum« - vorliegt. In einer solchen Struktur sind 
auch die Ikonen, die Sie vom Desktop her kennen, abgespeichert; ebenso die Dialogboxen, auf 
die wir im nächsten Abschnitt zu sprechen kommen. Ein Objektbaum besitzt also eine recht 
komplexe Struktur, daher ist es aufwendig, ihn selbst zu programmieren. Diese Arbeit wird 
durch ein Hilfsprogramm, dem sogenannten »Resource-Construction-Set«, einem Editor für 
Objektbäume, bedeutend erleichert. Ein solches Programm läßt sich ganz preiswert erwerben. 
Beim Megamax-System wird ein Resource-Construction-Set mitgeliefert. Hiermit kann man 
bei der Erstellung die Bildschirmoberfläche so vor sich sehen, wie sie später im Programm er¬ 
scheinen soll. Der Resource-Construction-Set speichert die Objektbäume - also den gesamten 
Bildschirmzauber aus Menüs, Dialog- und Alarmboxen sowie Ikonen in einer »Resource- 
Datei« (mit der Endung ».RSC«). Diese Datei kann dann mit der Prozedur 
AESResources. LoadResource in ein Modula-Programm geladen werden. Die Prozedur 
AESMenues. MenuBar bringt das Menü auf den Bildschirm. 
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Titel 2 


Sie wählten den Menüpunkt Mahl 2| 
Sie wählten den Menüpunkt Mahl 3 


Titel i 


nMillill 


Desk 


Bild 4.20: Ein Pull-down-Menü 

In dem Resource-File sind alle Objekte (Menüpunkte) willkürlich durchnumeriert. Glück¬ 
licherweise erzeugt das Resource-Construction-Set einen externen Modul (bestehend aus Im- 
plementations- und Definitions-Datei), in dem die Menüpukte als Konstanten definiert sind. 
Diese Bezeichner wurden zuvor mit dem Resource-Construction-Set deklariert: 


DEFINITION MODULE Menuel; 
CONST 


Menue = 

0; 



0 

* Menuebaum 

*) 

Titell 

4; 

( 

* TITLE 

in 

Baum 

MENUE 

*) 

Titel2 

5; 

( 

* TITLE 

in 

Baum 

MENUE 

*) 

Titel 

8; 

(* 

STRING 

in 

Baum 

MENUE 

*) 

Wahll 

17; 

(* 

STRING 

in 

Baum 

MENUE 

*) 

Wahl 2 

18; 

c* 

STRING 

in 

Baum 

MENUE 

*) 

Ende = 

19; 

(* 

STRING 

in 

Baum 

MENUE 

*) 

Wahl 3 

21; 

(* 

STRING 

in 

Baum 

MENUE 

*) 

Wahl 4 

END Menuel. 

22; 

(* 

STRING 

in 

Baum 

MENUE 

*) 


Der zugehörige Implementationsmodul enthält nur Compileroptionen, ansonsten ist er leer. 
Es handelt sich also bei Menuel um einen reinen Datenmodul (vgl Abschnitt 1.7.5) 
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IMPLEMENTATION MODULE Menuel; 

(*$N+*) (* Runtime-Modul wird nicht automatisch importiert *) 

(* Keine Prozedurnamen im erzeugeten Code *) 

END Menuel. 


Dieser Modul kann ganz normal übersetzt und importiert werden; damit stehen dem Pro¬ 
gramm dann die Konstanten zur Verfügung. 

Um nun das Menü auf den Bildschirm zu bringen, sind folgende Schritte nötig: 

1. Anmelden beim GEM wie gewohnt. 

2. Das Resource-File, welches (unter anderem) das Menü enthält, von der Diskette in den 
Speicher laden (mit LoadResource ) 

3. Man besorgt sich einen Pointer auf das Menü. Dies erledigt die Prozedur Res ourceAddr. 
Sie benötigt die Nummer, die unser Menü im Resorce-File besitzt: Dafür benötigen wir die 
Konstante Menue aus dem vom RCS erzeugten Modul. 

4. Das Menü wird mit MenuBar angezeigt. 

Die Sequenz im einzelnen: 

IMPORT Menuel; (* Das vom RCS erzeugte Modul *) 


<. . . > 

Grafik.anmelden; (* 1 *) 
LoadResource(”A: \MENUE1. RSC”); (* 2 *) 
UnserMenue = ResourceAddr(treeRsrc, Menuel.Menue); (* 3 *) 
MenuBar(UnserMenue, TRÜE); (* 4 *) 


Das Menü ist nun auf dem Bildschirm. Jetzt muß man nur noch warten, bis der Benutzer einen 
Menüpunkt anwählt. Dazu ruft man die Prozedur MessageEvent (engl. event= Ereignis) 
auf, der man eine Variable vom Typ MessageBuffer übergeben muß: 

VAR Nachricht: AESEvents.MessageBuffer; 

<. . . > 

AESEvents.MessageEvent (Nachricht); 


Enthält nun Nachricht. msgType den Wert menuSelected, so hat der Benutzer einen 
Menüpunkt angewählt. Die Nummer des Menüpunktes befindet sich dann in Nach¬ 
richt. selltem. 
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MODULE MenueTest; 

PROM Terminal IMPORT WriteString, WriteLn, KeyPressed, GotoXY; 

PROM Grafik IMPORT anmelden, abmelden; 

PROM GEMEnv IMPORT GemError; 

PROM GEMGlobals IMPORT PtrObjTree; 

PROM AESMenus IMPORT MenuBar, NormalTitle, Checkitem; 

PROM AESEvents IMPORT MessageBuffer, MessageEvent, menuSelected; 

PROM AESResources IMPORT LoadResource, PreeResource, ResourceAddr, ResourcePart; 
PROM Menuel IMPORT Wahll, Wahl2, Wahl3, Ende; 

(* Menuel enthält die Menüpunktnummern als Konstanten *) 

VAR SchalterWahl3 : BOOLEAN; 

PROCEDURE pl; 

BEGIN 

WriteLn; WriteString(”Sie wählten den Menüpunkt Wahl 1”) 

END pl; 

PROCEDURE p2; 

BEGIN 

WriteLn; WriteString(”Sie wählten den Menüpunkt Wahl 2”) 

END p2; 

PROCEDURE p3(M : PtrObjTree); (* Menüpunkt mit Häkchen behandeln *) 

BEGIN 

SchalterWahl3 := NOT SchalterWahl3; (* Schalter umschalten *) 

Checkitem(M, Wahl3, SchalterWahl3); (* Häkchen löschen/setzen *) 

WriteLn; 

IP SchalterWahl3 

THEN WriteString(”Sie haben den Menüpunkt Wahl 3 eingeschaltet”) 

ELSE WriteString(”Sie Haben den Menüpunkt Wahl 3 ausgeschaltet”) 

END p3; 

PROCEDURE ende; 

BEGIN 

WriteLn; 

WriteString(”Sie wählten den Menüpunkt Ende. Bitte Taste drücken.”); 

REPEAT UNTIL KeyPressed() 

END ende; 

PROCEDURE messageHandler(M : PtrObjTree) : BOOLEAN; 

VAR mb : MessageBuffer; 

BEGIN 
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MessageEvent(mb); (* Wartet auf ein Ereignis *) 


CASE mb.msgType 

OF 

(* Welches 

Ereignis ist eingetreten? *) 

menuSelected : 


(* Ereignis: ein 

Menüpunkt wurde angewählt *) 

CASE mb.selltem OF 



Wahll : 

pl 1 




Wahl2 : 

p2 | 




Wahl3 : 

p3 | 




Ende 

ende; 

RETURN TRUE 

(* 

fertig *) 

END; 





NormalTitle(M, 

mb.selTitle, TRUE); 

(* Titel wieder 

normal *) 

ELSE END; (* Die anderen Record-Komponenten i 

3ind hier nicht von 

Belang *) 


RETURN FALSE (* noch nicht fertig *) 


END messageHandler; 

PROCEDURE arbeiten; 

VAR M : PtrObjTree; 

BEGIN 

LoadResource(”F: \MENUE1. RSC”); (* Resource File ins Programm laden *) 

(* Achtung: Pfadnamen geeignet anpassen ! *) 
IF GemError() THEN HALT END; (* Fehler beim Laden, dann Abbruch *) 

M := ResourceAddr(treeRsrc,Menue); (* treeRsrc aus Typ ResourcePart *) 

MenuBar(M,TRUE); 

GotoXY(0,10); 

SchalterWahl3 : = TRUE; 

REPEAT UNTIL messageHandler(M) 

END arbeiten; 

BEGIN 

anmelden; 
arbeiten; 
abmelden 
END MenueTest. 


Wie man sieht, ist der Umgang mit Pull-down-Menüs sehr elegant in Modula mit einer 
CASE-Anweisung zu erledigen. Diese Fallunterscheidung steht in einer Schleife und ruft so¬ 
lange die zugeordneten Prozeduren auf, bis der Benutzer sich für den Menüpunkt »Ende« ent¬ 
schlossen hat. 

Wenn Sie im Umgang mit dem Resource-Construction-Set noch unerfahren sind, hier noch 
ein kleiner Tip, bevor Sie eigene GEM-Bildschirme kreieren: Laden Sie sich zunächst die Re- 
source-Dateien anderer Programme in diesen Editor, und schauen Sie nach, welche Eigen¬ 
schaften den einzelnen Objekten jeweils mitgegeben wurden, um ihre speziellen Funktionen zu 
realisieren. Nehmen Sie dazu beispielsweise die Resource-Datei dieses Programms von der 
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Diskette oder die Ihrer Modula-Shell. Sie sollten aber grundsätzlich mit einer Kopie arbeiten, 
am besten auf einer R AM-Disk - da schnell im Resource-Construction-Set etwas versehent¬ 
lich abgeändert ist. Es wäre doch zu schade, wenn ihr Modula-System nicht mehr mit seiner 
Benutzeroberfläche klar käme! 


4.8 Benutzung von Dialogboxen 

Zum Abschluß wollen wir unseren Programmen noch den richtigen »Atari-Pep« geben: Bei unse¬ 
ren vorherigen GEM-Beispielen ging es in erster Linie um Ausgaben. Eingaben erfolgten bisher nur 
mit Mausklick (Eingabe von Punkten/Koordinaten) oder über die Knöpfe einer Alertbox. Ab und 
zu kommt man aber nicht umhin, auch in einem GEM-Programm zur Tasta¬ 
tur zu greifen, um Strings oder Zahlen einzugeben. Hierzu verwendet man »Dialogboxen«. Das 
Aussehen (Größe, Lage auf dem Bildschirm, Masken (der feste Text), Art der Eingaben (Buch¬ 
staben oder Ziffern) legt man am einfachsten mit dem Resource-Construction- Set fest. Wie bei den 
Menüs liest man dann im Modula-Programm die Resource-Datei mit der fertigen Dialogbox ein. 
Mit DrawOb j e c t wird die Box auf den Bildschirm gebracht. Der Benutzer kann nun in Ruhe seine 
Eingaben machen und beliebig verbessern und edieren. Erst wenn er mit dem Tippen fertig ist (was 
er im allgemeinen durch Anklicken eines mit »OK« beschrifteten Knopfes meldet), erhält das Pro¬ 
gramm die Kontrolle (und die ausgefüllte Dialogbox) zurück. 

MShell Datei Optionen Tools 



Bild 4.21: Eine Dialogbox 
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Wie bringt man nun eine Dialogbox, die man mit dem RCS erzeugt hat, von seinem Programm 

aus auf den Bildschirm? Kein Problem, wenn man sich genau an das folgende Rezept hält: 

1. Wie immer: Beim GEM anmelden. Am einfachsten natürlich mit unserer Prozedur 
Grafik, anmelden. 

2. Das Resource-File, das die Dialogbox enthält, mit LoadResource von der Diskette in 
den Speicher laden. Das Resource-File kann noch weitere Dialogboxen oder Menüs ent¬ 
halten. Wichtig: Es darf nur EIN Resource-File geladen werden. 

3. Man besorgt sich einen Pointer auf die Dialogbox. 

4. Den Bereich, den die Box auf dem Bildschirm belegt, (mitFormDial(reserveForm, . . . ) 
reservieren. Dazu benötigen wir die Größe der Dialogbox (als Rechteck), welche die Funk¬ 
tion FormCenter liefert. 

5. Man kann mit FormDial (growForm, . . . ) den bekannten »Zoom«-Effekt beim Aufge¬ 
hen von Fenstern erzeugen. Dazu wird ein kleineres Rechteck (in unserem Beispiel box¬ 
klein) benötigt, das dann auf die Größe von box»gezoomt« wird. Dieser Schritt ist mehr 
ein Gag und kann entfallen. 

6. Die Box mit DrawObjekt auf den Bildschirm bringen. 

7. Den Dialog einleiten mit Fo rmDo . Die Box steht nun dem Anwender zur Verfügung, bis sie 
durch Anklicken des OK- oder Abbruch-Knopfes verlassen wird. Die Nummer des Knop¬ 
fes, mit dem der Benutzer den Dialog beendet hat, steht im 3. Parameter von FormDo. 

8. Für den Abgang der Box kann wieder ein »Zoom-Effekt« erzeugt werden, diesmal in um¬ 
gekehrter Richtung: FormDial ( shrinkForm, boxklein, box) . Anmerkung: auch hier 
steht das kleinere Rechteck zuerst in der Parameterliste. 

9. Die Box wieder abmelden: FormDial ( f reeForm, . . . ) 

Anmerkung: die Schritte 1 bis 3 sind nur einmal im gesamten Programm erforderlich. 

Für einen erneuten Dialog mit der Box sind die Schritte 4 bis 9 zu wiederholen. 

IMPORT Dialogl; (* das vom RCS erzeugte Datenmodul *) 


VAR 

UnserDialog: GEMGlobals.PtrObjTree; 
box, 

boxklein: Rectangle; 


(* für die Größe der Box *) 
(* für den ZOOM-Effekt *) 


c. . . > 


Grafik, anmelden; 

AESResources. LoadResource(”DIALOGl.RSC”); 


(* 2 *) 
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UnserDialog := ResourceAddr(treeRsrc, Dialog); 


(* 3 *) 


c. . . > 


FormDial(reserveForm, boxklein, box); 
FormDial(growForm, boxklein, box); 


(* 4 *) 

(* & *) 
(* 6 *) 
(* 7 *) 
(* 8 *) 
(* 9 *) 


DrawObject(UnserDialog, Root, MaxDepth, box); 
FormDo (UnserDialog,Root, EndeKnopf); 


PormDial(shrinkPorm, boxklein, box); 
PormDial(freePorm, boxklein, box) 


Nun tritt die Schwierigkeit auf, an die eingegebenen Daten heranzukommen. Hierzu gibt es 
zwei Möglichkeiten: 

1. Wir sagen der Dialogbox, wohin sie die Eingaben schreiben soll. Das geschieht mit der 
Prozedur Obj Händler. LinkTextString, deren erster Parameter die Nummer des Feldes 
in der Dialogbox ist. Diese erhält man aus dem Resource-Construction-Set erzeugten De¬ 
finitionsmodul. Der zweite Parameter ist die Adresse einer String-Variablen, die die Daten 
aufnehmen soll. Alle Anwendereingaben in der Dialogbox gelangen also direkt ans rich¬ 
tige Ziel. Zu beachten ist noch, daß sämtliche Eingaben von Zeichenketten aufgenommen 
werden, Zahlen müssen nachträglich umgewandelt werden. Wichtig ist hierbei, daß zuvor 
bei der Arbeit mit dem Resource-Construction-Set die maximal benötigte Stringlänge 
korrekt vordefiniert worden ist. Sie muß auch unbedingt mit der Länge des aufnehmen- 
denden Strings übereinstimmen. Bei einem kürzeren Zielstring könnte es andernfalls pas¬ 
sieren, daß ungewollt Speicherbereich überschrieben wird, denn die Prozedur LinkText¬ 
String kennt ja nur dessen Adresse. Es findet also keine Bereichskontrolle statt, die Pro¬ 
grammiersprache »C« läßt grüßen! 

2. Ohne besondere Vorkehrungen werden die Eingaben in die Dialogbox automatisch im 
Objektbaum selbst gespeichert. Er hält den nötigen Speicherplatz hierfür bereit. Man 
braucht nur noch den String in eine Variable des Klientenprogramms zu kopieren. Dies 
leistet die Prozedur Ob j Händler. GetTextStrings. Ihre Parameter sind Nummer des be¬ 
treffenden Feldes in der Dialogbox und der Zielstring. Die beiden weiteren Parameter ent¬ 
halten die zuvor im Resource-Construktion-Set festgelegten Stringmasken und sind hier 
nicht von Belang. 

Zunächst folgt wieder zum besseren Verständnis der vom Resouce-Construktion-Set erzeugte 
Datenmodul: 

DEFINITION MODULE Dialogl; 


CONST 

Dialog 


0 ; 


(* Formular/Dialog *) 
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Titel 

1; 

(* BOXTEXT 

in 

Baum 

DIALOG 

*) 

Nachname = 

3; 

(* FTEXT 

in 

Baum 

DIALOG 

*) 

Vorname = 

4; 

(* FTEXT 

in 

Baum 

DIALOG 

*) 

Alter = 

5; 

(* FTEXT 

in 

Baum 

DIALOG 

*) 

Quit = 

6; 

(* BUTTON 

in 

Baum 

DIALOG 

*) 

Ok 

7; 

(* BUTTON 

in 

Baum 

DIALOG 

*) 


END Dialogl. 


IMPLEMENTATION MODULE Dialogl; 
(*$N+,M-*) 

END Dialogl. 


Das Demonstrationsprogramm zeigt beide besprochenen Möglichkeiten, die Eingaben »ab¬ 
zuholen«. Damit Sie sehen, daß alles korrekt funktioniert, werden die geänderten Strings an¬ 
schließend einfach auf den Bildschirm geschrieben. 


MODULE DialogTest; 


FROM 

SYSTEM 

IMPORT 

FROM 

InOut 

IMPORT 

FROM 

Grafik 

IMPORT 

FROM 

GEMG1obals 

IMPORT 

FROM 

GEMEnv 

IMPORT 

FROM 

GrafBase 

IMPORT 

FROM 

ObjHändler 

IMPORT 

FROM 

AESObjects 

IMPORT 

FROM 

AESForms 

IMPORT 

FROM 

AESResources 

IMPORT 

FROM 

Dialogl 

IMPORT 

TYPE 




ADDRESS, ADR; 

WriteString, WriteLn, Read; 
anmelden, abmelden; 

PtrObjTree, Root, MaxDepth, OStateSet; 
GemError; 

Rectangle, Reet; 

LinkTextString, GetTextStrings, 

SetCurrObjTree, SetObjState; 

DrawObject; 

EormCenter, PormDial, FormDo, PormDialMode; 
LoadResource, FreeResource, ResourceAddr, 
ResourcePart; 

Dialog,Nachname, Vorname, Alter, Ok, Quit; 


str80 = ARRAY[0..79] OF CHAR; 


VAR 


dlogstr : RECORD 

Name, Vorname : str80; 
Alter : str80 

END; 

dlogBaum : PtrObjTree; 
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PROCEDURE ResourceBauen; 

BEGIN 

LoadResource(”DIAL0G1.RSC”); (* Resource Pile ins Programm laden *) 

IP GemError() THEN HALT END; (* Pehler beim Laden, dann Abbruch *) 

dlogBaum := ResourceAddr(treeRsrc, Dialog); 

SetCurrObjTree(dlogBaum,PALSE); 

LinkTextString(Nachname, ADR(dlogstr. Name)); (* 1. Möglichkeit *) 

LinkTextString(Vorname, ADR(dlogstr.Vorname)); 

dlogstr.Name := ”B.L. Ödraann”; (* Strings vorbesetzen *) 

dlogstr.Vorname := ”” 

END ResourceBauen; 

PROCEDURE BoxZeigen(bäum: PtrObjTree): CARDINAL; 

VAR 

boxklein, box : Rectangle; 

EndeKnopf : CARDINAL; 

BEGIN 

boxklein : = Reet(200,200, 50,30); 
box := PormCenter(baum); 

J PormDial(reservePorm, boxklein, box); (* Bildschirmbereich reservieren *) 
PormDial(growForm, boxklein, box); 

DrawObject(bäum, Root, MaxDepth, box); 

PormDo(baum, Root, EndeKnopf); 

FormDial(shrinkPorm, boxklein, box); 

FormDial(freePorm, boxklein, box); 

RETURN EndeKnopf 
END BoxZeigen; 

PROCEDURE arbeiten; 

VAR 

c : CHAR; 

dummy : str80; 

BEGIN 

ResourceBauen; (* Resourcen laden und vorbelegen *) 

WHILE BoxZeigen(dlogBaum) = Ok DO 

SetCurrObjTree(dlogBaum, PALSE); 

GetTextStrings(Alter, dlogstr.Alter, dummy,dummy); (* 2. Mögl. *) 

WITH dlogstr DO 

WriteLn; WriteString(”Sie heißen: ”); 

WriteString(Vorname); WriteString(” ”); WriteString(Name); 
WriteLn; WriteString(”Ihr Alter: ”); WriteString(Alter) 

END; 


(* Effekt: Zoom klein --> groß *) 
(* Dialogbox zeichnen *) 
(* Benutzereingaben *) 
(* Effekt: Zoom groß --> klein *) 
(* Bildschirmbereich freigeben *) 
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SetObjState(Ok, OStateSet{)); (* OK-Taste wieder abschalten *) 

END; 

WriteLn; WriteString(”Das wars dann wohl.... <Taste>”); 

Read(c); 

END arbeiten; 

BEGIN 

anmelden; 
arbeiten; 
abmelden 
END DialogTest. 

Das Programm soll nur die Programmiertechnik von Dialogboxen verdeutlichen; ansonsten 
hat es keinen eigenständigen Wert. Im Kapitel 5 sehen Sie aber das Zusammenspiel von Dia¬ 
logboxen, Menüleisten, Alertboxen und Grafik in einer komplexen Anwendung. 


4.9 Benutzung des SSWiS-Moduls 
bei SPC-Modula 

Wie eingangs erwähnt, wurden die GEM-Beispiele dieses Buchs mit dem Megamax- 
Modula-System entwickelt. Sie lassen sich aber auf jedes andere Modula-System für den Atari 
ST übertragen, da diese sämtlich über Module mit AES- und VDI-Routinen verfügen. Nun 
wollen wir hier noch auf eine Eigenheit, besser gesagt Spezialität, von SPC- Modula eingehen. 

Ein Teil unserer Beispiele zeigte, daß GEM-Programme auf Vorarbeiten mit einem 
Resource-Construction-Set basieren. Dies wird nicht als Nachteil erscheinen, wenn man eine 
komplexe GEM-Umgebung in einem Programm wünscht, da sich alle Elemente (Menüzeilen, 
Dialog- und Alertboxen, Programmlogo) in einem Arbeitsgang erzeugen lassen. Für eine 
kleinere Anwendung, in der man beispielsweise nur eine Dialogbox und ein Fenster benötigt, 
ist es jedoch etwas umständlich. 

Bei SPC-Modula gibt es einen Modul »SSWiS« (= Small Systems Windowing Standard) mit 
dem sich einfach fensterorientierte Programme schreiben lassen. Die Verfasser erhoffen sich 
von SSWiS zudem eine Verbreitung auf andere Rechner, so daß eine systemunabhängige ein¬ 
heitliche Fensterschnittstelle bereit stünde, die die Portierung von Modula-Programmen auf 
andere Rechner weiter vereinfachen würde. 

Neben einer einfach zu bedienenden Fensterverwaltung bietet SSWiS eine handliche Mög¬ 
lichkeit zur Erzeugung von Alert- und Dialogboxen. Die SSWiS-Alertboxen - sie heißen hier 
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Notizboxen - sind denen des GEM recht ähnlich. Sie besitzen zwar kein Icon, gestatten dafür 
aber bis zu vier Knöpfe. 

Die SSWiS-Dialogboxen haben ebenfalls eine standardisierte Form und lassen sich praktisch 
mit einem einzigem Prozeduraufruf bewerkstelligen. Sie bestehen aus einer Meldungstextzeile 
und einer edierbaren Zeile. Neben den gewohnten Quittungtasten zur Dialogbeendigung 
kann man noch »Optionstasten« für Voreinstellungen programmieren, die durch Anklicken 
mit der Maus an- bzw. abgeschaltet werden können. 

Eine besondere Form des Dialogs stellt das »Identifikationsformular« dar, das bei SSWiS 
anstelle des Programmlogos tritt. Die Identifakationsbox erscheint nach Anwahl des ersten 
Menüeintrags der ersten Menüspalte. Das Pulldown-Menü hat unter SSWiS das übliche Aus¬ 
sehen und Bedienungsart. Es kann vom Programm aus mit wenigen Prozeduraufrufen erzeugt 
werden. 

Besonders zu erwähnen ist noch, daß unter SSWiS mehrere Anwendungen quasiparallel ab¬ 
laufen können. Ein gutes Beispiel hierfür ist die Shell des SPC-Systems, in der man die Ausgabe 
eines Programms in einem Fenster gleichzetig mit dem Quelltext in einem anderen Fenster 
sehen kann. Jede SSWiS-Anwendung erhält ihren eigenen Menübalken. Es können also meh¬ 
rere Menüs verwaltet werden. Sichtbar ist immer das Menü, das zu der Anwendung gehört, 
deren Fenster momentan »aktuell« ist. Das aktuelle Fenster ist dabei das oberste Fenster. 

Alles bisher Gesagte soll nun in einem kleinen Programm »SSWiSDemo« gezeigt werden, also 
Menüleiste, Dialogbox, Notizboxen, Identifikationsbox und ein Fenster. 

Das Menü hat den Titel »Kommando« mit den Einträgen »Satz eintragen«, »Alertbox«, 
»Ende«. Beim Anklicken von »Satz eintragen« erscheint eine Dialogbox zur Eingabe eines 
Strings. Dieser String wird dann in eine zufällige Zeile eines Textfensters geschrieben. SSWiS 
selbst stellt nur die reine Fensterverwaltung dar, zur Ausgabe von Text oder Grafik gibt es hier 
keine Prozeduren. Zur Textausgabe benötigt man Prozeduren aus dem Modul »Text- 
Windows«. TextWindows organisiert ein Fenster statt in »Weltkoordinaten« in Textzeilen 
und -spalten. 

Klickt man in der äußersten linken Menüleiste »SSWiS Demo« an, so wird die Identifika¬ 
tionsbox geöffnet. Das Programm terminiert durch die <Esc>-Taste oder Anwahl des 
Menüpunktes »Ende«. 

Während des Programmablaufs kann man die Größe und Lage des Textfensters mit der Maus 
manipulieren. Das Textfenster läßt sich auch schließen, wodurch automatisch unsere Menü¬ 
zeile verschwindet. Da unser Fenster jetzt nicht mehr aktuell ist, erscheint das Menü von 
SSWiS, das die Anwahl des SPC-Programmlogos gestattet. Unser Fenster läßt sich aber jeder¬ 
zeit wieder öffnen. Hierzu befindet sich am unteren linken Bildschirmrand ein Rechteck mit 
dem Namen der Anwendung. Durch Anklicken dieses Rechteckbereichs lebt sie wieder auf. 
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Diesen ganzen Bildschirmzauber verwaltet SSWiS selbst, er braucht also nicht explizit pro¬ 
grammiert zu werden. 

Was bleibt nun noch für den Programmierer einer SSWiS-Anwendung zu tun? Grob gesagt, 
geht es um das Anmelden der Anwendung beim SSWiS, wobei einige Arbeitsprozeduren 
übergeben werden müssen, gefolgt vom Aufruf einer Arbeitsschleife und schließlich vom Ab¬ 
melden. Die Arbeitsprozeduren hat der Programmierer bereitzustellen. 

Im einzelnen zeigt das Hauptprgramm von SSWISDemo die typische Vorgehensweise: 

1. Die Anwendung meldet sich mit SSWiS. Register(Client, ”SSWiS Demo”, Accept) 
als »Kunde« beim SSWiS an (Prozedur Init), indem dort eine Prozedur Accept überge¬ 
ben wird, die auf alle Benutzertätigkeiten reagieren soll. Sie entspricht der Prozedur mes- 
sageHandler aus dem Abschnitt 4.7. Sie reagiert also auf Ereignisse wie Tastendruck, 
Mausclick, Menüanwahl, Timerevents usw. in einer CASE-Anweisung. In unserem Fall 
wird von hier aus der Prozeduraufruf DialogDemo oder AlarmDemo, das Erscheinen der 
Identifikationsbox und das Setzen des Exitflags zur Programmbeendigung bewirkt. Ver¬ 
allgemeinert ist die Accept-Prozedur also diejenige Routine, mit der SSWiS später arbeiten 
soll. 

2. In der Prozedur Openerfolgt die Initialisierung des benötigten Textfensters durch Text- 
Windows. Create (Client, Eens t er, Re störe ). Bei der Ereignisbehandlung kann es 
Vorkommen, das Bereiche des Fensters restauriert (neu geschrieben) werden müssen. 
Dazu benötigt SSWiS eine Prozedur Re s t o r e . Die Restore-Prozedur wird von SSWiS au¬ 
tomatisch aufgerufen, wenn ein Neuzeichnen erforderlich ist, beispielsweise nach dem 
Schließen einer Dialogbox, die das Fenster teilweise verdeckte. Sie muß dann in der Lage 
sein, das Fenster (oder Teile davon) zu rekonstruieren. Dazu muß sie den gesamten Inhalt 
des Fensters kennen. In unserem Programm erreichen wir das durch ein globales Feld 
Zeilen, in dem alle Zeilen des Fensters als String gespeichert sind. 

Weiterhin werden in Opendie Mindest-, Ideal- und Maximalgröße des Fensters, seine Be¬ 
dienungselemente und die Menüeinträge definiert. Anschließend öffnet man das Fenster 
in Idealgröße und das Menü erscheint automatisch. 

3. Sobald diese Initialisierungen durchgeführt sind, ruft man SSWiS. PollEvents solange 
auf, bis der Benutzer den Programmabbruch auslöst (Prozedur Arbeiten). Hierdurch 
wird die Ereignisbehandlungsschleife ausgeführt. 

4. Mit der Prozedur Close wird das Fenster wieder geschlossen. 

5. Die Prozedur Term meldet dann die Anwendung beim SSWiS wieder ab. 

Das Programm SSWISDEM.PRG findet sich auf der Diskette 2 im Ordner SPC. Hier gibt es 
auch das Quellfile (mit der Endung .MOD, im Gegensatz zu Megamax-Modula, wo Quellfiles 
auf .M enden!) und das übersetzte, aber ungelinkte Objektfile. Zusätzlich ist noch die Datei 
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SSWISS.RSC nötig, die von SSWiS automatisch geladen wird. Sie wird vom SPC-Hersteller 
mitgeliefert. Der Hersteller beabsichtigt, in einer neuen Version diese Datei gänzlich ver¬ 
schwinden zu lassen und die Daten in den SSWiS-Modul zu integrieren. 

Am besten, Sie lassen das Programm gleich laufen und testen alles am Rechner aus, während 
Sie das Quellfile studieren. Die restlichen Fragen dürften sich dann klären, zumal der Text be¬ 
sonders ausführlich kommentiert wurde. Bleibt noch zu erwähnen, daß die Vorlage für dieses 
Programm von Andreas Gauger (von advanced applications Viczena) stammt, wofür wir ihm 
hiermit danken. 

MODULE SSWiSDemo; 

IMPORT SSWiS,TextWindows,Strings, Clock; 

CONST 

MaxZeilen = 50; ( * Maximale Höhe des Textfensters * ) 

MaxSpalten = 79; ( * Maximale Breite des Textfensters * ) 

TYPE 

INDEX = INTEGER; 

(* Bei SPC sind Peldindices vom Typ INTEGER; ebenso HIGH(feld) * ) 

Zeile = ARRAY [0..MaxSpalten] OE CHAR; 

(* Typdeklaration für eine Bildschirmzeile * ) 

VAR 

Zeilen : ARRAY [0..MaxSpalten] OE Zeile; (* Feld von Zeilen * ) 
Client : SSWiS.ModuleHandles; (* SSWiS-Client-Kennung * ) 

Fenster : SSWiS.WindowHandles; (* Fenster-Kennung * ) 

ExitFlag : BOOLEAN; (* Flag für Programmende * ) 

(* Die Restore-Prozedur wird vom SSWiS vollautomatisch aufgerufen, wenn 

* ein Teil des Fensters neu aufgebaut werden soll, SSWiS übergibt den 

* Bereich, der regeneriert werden muß, in Clipxy und Clipwh. 

* ) 

PROCEDURE Restore( 

Owner : SSWiS.ModuleHandles; (* SSWiS-Client-Kennung * ) 

Fenster : SSWiS.WindowHandles; (* Fenster-Kennung * ) 

Clipxy, 

Clipwh : TextWindows.Points); (* neuzuzeichnedes Rechteck * ) 

VAR 

y : INDEX; (* Zeilenzähler * ) 

Ausschnitt : Zeile; (* Zwischenspeicher für die neue Zeile * ) 
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Position : TextWindows.Points; (* Positions-Zwischenspeicher * ) 


BEGIN 

Position.X:=Clipxy.X; (* X-Position des zu zeichnenden Rechtecks * ) 

FOR y := Clipxy.Y TO Clipxy.Y+Clipwh. Y DO (* alle Zeilen des Rechtecks * ) 
Position.Y : = y; (* Y-Position der momentanen Zeile * ) 

TextWindows.Position(Position); 

(* Positioniere TextWindow’s interne Schreibmarke 
...Fehler im Handbuch: nicht der Caret wird positioniert * ) 

Strings.Copy(Zeilen[y],Clipxy.X,Clipwh.X, Ausschnitt); 

(* Benötigten Ausschnitt aus dem Zeilenfeld ausschneiden * ) 
TextWindows.WriteString(Ausschnitt); (* ... und dann ausgeben * ) 

END; 

(* Man könnte auch die ganze Zeile ausgeben, SSWiS fängt alle 

* Zeichen außerhalb des Rechtecks ab, aber es dauert länger. 

* ) 

END Restöre; 


(* liefert eine Zufallszahl zwischen 0 und bereich-1: * ) 

PROCEDURE Zufall(bereich: LONGINT) : INDEX; 

VAR 

SystemZeit : Clock.Time; 

BEGIN 

Clock.Get(SystemZeit); (* Holt die aktuelle Uhrzeit * ) 

RETURN (SystemZeit.Millisec DIV 5D) MOD bereich 
END Zufall; 

(* Die Prozedur DialogDemo erfragt einen Satz vom Benutzer, der 

* dann in einer zufällig gewählten Zeile des Fensters dargestellt wird. 

* Diese Routine demonstriert den wichtigen ’ExplicitRestore’-Aufruf, der 

* die einzige erlaubte Möglichkeit darstellt, Bereiche im Fenster vom 

* Programm aus neuzuzeichnen 

* ) 

PROCEDURE DialogDemo; 


VAR 

Eingabe 

Options 

Knopf 

y 

Restxy, 

Restwh 

BEGIN 

Eingabe := 
Knopf := 0; 


(* Eingegebener Satz 
(* Dummy 

(* Gedrückter Exit-Knopf 


Zeile; 

BITSET; 

INTEGER; 

INDEX; 

(* Übergabevariablen für ExplicitRestore 
TextWindows.Points; 


(* String ’leer machen’ * ) 


(* Default-Knopf setzen * ) 
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SSWiS. AskForm (* SSWiS-Frage-Formular mit Exit-Knöpfen Fertig & Abbruch * ) 
(”Dialogbox-Demo: Geben Sie einen Satz ein!”, 

”Fertig!Abbruch”, Eingabe, Options, Knopf); 

IF Knopf=0 THEN (* Wenn der Fertig-Knopf gedrückt wurde * ) 

y := Zufall(MaxZeilen); (* Zufallszeile für Ausgabe wählen * ) 

Strings.Copy(Eingabe,0,Strings.Length(Eingabe), Zeilen[y]); 

(* Den eingegebenen Satz ins Zeilen-Feld kopieren * ) 
Zeilen[y][Strings.Length(Eingabe)]: =’ ’; (* String-Ende-Marke weg * ) 

(* Die y-te Zeile des Textes muß neu geschrieben werden. Dafür werden die 

* Koordinaten des neuzuzeichnenden Rechtecks (”Clipping-Rechteck”) gesetzt 

* und anschließend ’TextWindows.ExpilicitRestore’ aufgerufen: * ) 

Restxy.X:=0; (* ’Clipping’-Rechteck definieren... * ) 

Restxy.Y:=y; 

Restwh.X:= MaxSpalten+1; 

Restwh.Y:=1; 

TextWindows.ExplicitRestöre(Client,Fenster, Restxy, Restwh); 

END; 

END DialogDerao; 

(* Diese Prozedur demonstriert die Alert-Boxen. 

* ) 

PROCEDURE AlarmDemo; 

VAR 

Knopf : INTEGER; (* gedrückter Exit-Knopf * ) 

BEGIN 

Knopf : = 0; (* Default-Knopf ist der erste von links * ) 

SSWiS.NotifyForm (* Alert-Box darstellen * ) 

(”Dies ist eine ’ Notiz-Box’”, ”Warum?|Notiz?[Autor?”, Knopf); 

CASE Knopf OF 

0: (* 1. Knopf von links gedrückt * ) 

Knopf:=-l; (* diesmal kein Default-Knopf * ) 

SSWiS.NotifyForm (* und noch eine Alertbox * ) 

(”Nur zur Demonstration”,”Genial!”, Knopf) | 

1: (* 2. Knopf von links gedrückt * ) 

Knopf: =~1; 

SSWiS.NotifyForm 

(”SPC Entwickler machen aus Alert->Notiz”, ”Soso”, Knopf) | 

2: (* 3. Knopf von links gedrückt * ) 

Knopf: ss-l; 

SSWiS.NotifyForm 

(”Der Autor heißt: siehe Menü ’Demo’”, ”Danke”, Knopf) 

ELSE 

END; 

END AlarmDemo; 
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SSWiS.ModuleHandles; (* SSWiS-Klient-Kennung * ) 
SSWiS. WindowHandles; (* Fenster-Kennung * ) 
SSWiS.EventReports); (* aufgetretenes Ereignis * ) 


(* Die Accept-Prozedur wird vom SSWiS aufgerufen, wenn ein Ereignis aufge- 

* treten ist, z.B. eine Maustaste oder eine normale Taste wurde gedrückt, 

* oder ein Menüpunkt wurde angewählt usw. 

* ) 

PROCEDÜRE Accept(Owner 

Fenster 
VAR SReport 

BEGIN 

WITH SReport DO 
CASE Type OF 
SSWiS.Keyboard: 

CASE Strokes.Keys[0] OF 
27: ExitFlag: =TRUE 
ELSE 
END | 

SSWiS.Mouse: (* Wenn eine Maustaste gedrückt wurde * ) 

(* Dann passiert in diesem Programm gar nix * ) | 

SSWiS. Menu: (* Wenn ein Menüpunkt angewählt wurde * ) 

CASE Selection.Title OF 

0: (* Wenn es ein Menüpunkt im zweiten Menü von links war * ) 

CASE Selection.Item OF 


(* Wenn eine Taste gedrückt wurde 
(* Esc-Taste => Programmende 


0: DialogDemo | (* 

2: AlarmDemo (« 

4: ExitFlag:=TRUE (« 

ELSE 
END 

ELSE 
END | 

SSWiS. Identification: 

SSWiS.Identify( 

"SSWiS-Demonstrationsprogramm”, 
"Aus ’Modula-2 für den Atari ST 
"Dürholt / Schnur”, 
"Markt&Technik Verlag”); 

ELSE 

END 

END 

END Accept; 


1. MenüPunkt => DialogDemo * ) 
3. MenüPunkt => AlarmDemo * ) 
5. MenüPunkt => Programmende * ) 


(* Programm-Identifikation angefordert * ) 


(* Prog-Name * ) 
(* Version * ) 
(* Autor * ) 
(* Copyright * ) 


(* Diese oder ähnliche Prozeduren werden benutzt, wenn man die Kontrolle 

* an SSWiS übergeben will. 

* ) 

PROCEDÜRE Arbeiten; 

BEGIN 
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ExitFlag := FALSE; (* Programmende-Flag löschen * ) 

WHILE NOT ExitFlag DO (* Solange nicht ’ExitFlag’ gesetzt ist ... * ) 

SSWiS.PollEvents (* ... lassen wir SSWiS für uns arbeiten * ) 

END 

END Arbeiten; 

(* Initialisiert das Textfenster und setzt die Menüleiste * ) 

PROCEDURE Open; 

VAR 

ScrPos, ScrMinWh, ScrNorWh, ScrMaxWh : SSWiS.ScreenPoints; 

Worldxy, Worldwh : TextWindows.Points; 

BEGIN 

TextWindows.Create(Client, Fenster, Restore); 

(* Fenster initialisieren, die Restore-Prozedur wird mit übergeben * ) 
SSWiS.SetWindowElements( 

Client, Fenster, 

SSWiS.SetOfWindowElements{ (* alle Fensterelement setzen * ) 
SSWiS.Iconiser, SSWiS.MessageLine, 

SSWiS.XScroller, SSWiS. YScroller, 

SSWiS.Sizer, SSWiS.Füller} ); 

SSWiS.SetWindowTitle(Client, Fenster, ”SSWiS-Fenster”); (* Titel setzen * ) 

SSWiS. SetWindowMessage(Client, Fenster, ”Dies ist ein SSWiS-Fenster”); 

(* Infozeile setzen * ) 

ScrPos.X : = 10; (* Ausmaße des dargestellten Fensters in Punkten * ) 

ScrPos.Y := 20; 

ScrMinWh.X := 80; 

ScrMinWh.Y := 32; 

ScrNorWh.X := 320; 

ScrNorWh. Y := 160; 

ScrMaxWh. X : = 640; 

ScrMaxWh.Y := 400; 

SSWiS. PositionWindow(Client,Fenster, ScrPos); (* Fenster positionieren * ) 

SSWiS.SizeWindowContent(Client,Fenster, ScrMinWh, ScrNorWh, ScrMaxWh); 

(* minimale, normale und maximale Fensterausdehnung setzen * ) 
Worldxy.X := 0; (* Echte Ausmaße des Fensters in Zeichen (TextWindow) * ) 

Worldxy. Y := 0; 

Worldwh.X := MaxSpalten; 

Worldwh.Y := MaxZeilen; 

TextWindows.PositionWorld(Client,Fenster, Worldxy); 

(* Fenster innerhalb der ’Welt’ positionieren * ) 
TextWindows. SizeWorld(Client,Fenster,Worldwh); (* ’Welt*-Größe setzen * ) 

SSWiS. PlaceWindowOnTop(Client,Fenster); (* Fenster darstellen * ) 
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SSWiS. SetMenuTitle(Client, 0, ” [Kommando”); (* Menütitel setzen * ) 

(* Menüpunkte setzen. M=Maske: nicht anwählbar |(z.B. für Striche): * ) 
SSWiS.SetMenuItem(Client, 0,0, ” Satz eingeben”); 

SSWiS.SetMenuItem(Client, 0,1, ”M-”); 

SSWiS.SetMenuItem(Client, 0,2, ” Alertbox”); 

SSWiS. SetMenuItem(Client, 0,3, ”M j-”); 

SSWiS. SetMenuItera(Client, 0,4, ” ;Ende”) 

END Open; 

(* Diese Prozedur schließt das Fenster bei Programmende * ) 

PROCEDURE Close; 

BEGIN 

TextWindows.Delete(Client, Fenster) 

END Close; 

(* SSWiS-Applikation registriert und Accept-Prozedur übergeben * ) 

PROCEDURE Init; 

BEGIN 

SSWiS.Register(Client,”SSWiS-Demo”, Accept) 

END Init; 

(* Hier wird die SSWiS-Applikation abgemeldet * ) 

PROCEDURE Term; 

BEGIN 

SSWiS.Deregister(Client) 

END Term; 

(* Diese Prozedur füllt das Zeilen-Feld ’Zeilen’ mit Leerzeichen * ) 
PROCEDURE AlleZeilenLoeschen; 

VAR 

i : INDEX; (* Zeilenzähler * ) 

BEGIN 

FOR i : = 0 TO MaxZeilen DO (* Für alle Zeilen * ) 

Zeilenfi] := ””; (* Erst mal ’leer machen’ * ) 

Strings.Pad(Zeilen[i],MaxSpalten,” ”) (* und mit Leerzeichen füllen * ) 

END 

END AlleZeilenLoeschen; 


BEGIN 

AlleZeilenLoeschen; (* Zeilenfeld mit Leerzeichen füllen * ) 

Client:=1; (* vorsichtshalber mal setzen wegen Compiler-Fehler * ) 

Fenster:=1; 

Init; (* SSWiS Initialisieren * ) 

Open; (* Fenster öffnen, Menü setzen * ) 
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Arbeiten; 

(* SSWiS starten * ) 

Close; 

(* Fenster schließen * ) 

Term; 

(* Beim SSWiS abmelden * ) 

END SSWiSDemo. 



Wenn Sie mit SPC-Modula arbeiten und weiter in die SSWiS-Progammierung einsteigen wol¬ 
len, sei noch das Studium der Beispielprogramme »Terminal« (SSWiS-Version) und »Watch« 
aus dem SPC-Handbuch empfohlen. »Watch« zeigt die Programmierung der Analoguhr, die 
in der SPC-Shell erscheint. Hier handelt es sich um ein SSWiS-Fenster mit Grafik. Wie oben 
erwähnt, baut SSWiS beim Atari auf GEM auf, daher ist der Aufruf von AES- und VDI- 
Routinen in einer SSWiS-Anwendung durchaus angezeigt. 
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Kapitel 5 


Demonstration der 
Entwicklung eines 
komplexen Programmpaketes 
unter Modula-2 










410 


Entwicklung eines komplexen Programmpaketes unter Modula-2 


Zu dieser Thematik haben wir uns für ein Programm zum Zeichnen von Funktionsgraphen 
entschieden. »Schon wieder ein Plotprogramm. Das habe ich doch schon vor Jahren in Basic 
programmiert« wird da mancher Leser denken. Doch wir meinen, daß wir mit unserem Paket 
auch dem versierten Programmierer Einiges bieten können: 

• Eingabe des Funktionsterms als Zeichenkette mit anschließendem »Scannen« und »Par¬ 
sen«. Hier wird aber nicht zum hundertsten Mal der Standard-Wirth-Parser portraitiert, 
sondern es handelt sich um eine Eigenentwicklung, die aus der Zeichenkette einen »Funk¬ 
tionsbaum« erzeugt. Alle Funktionen der MathLib werden unterstützt. 

• Bestimmung der Ableitung der eingegebenen Funktion, aber nicht einfach numerisch 
durch Approximation der Tangentensteigung, sondern als Funktionsterm, also alge¬ 
braisch. Dabei wird gezeigt, wie man dem Computer Ableitungsregeln beibringen kann! 
Der erhaltene Term wird dabei nach gewissen Regeln optimiert. Das Regelwerk ist beliebig 
erweiterbar, wir benutzen hierbei Methoden der Kl-Programmierung (künstliche Intelli¬ 
genz). Man spricht hier von »symbolischer Mathematik«. 

• Integration einer Funktion, allerdings numerisch, da es für das Bilden der Stammfunktion 
bekanntlich keine festen Regeln gibt. Aber auch hier verlassen wir angetretene Pfade und 
bringen ein schnelles und stabiles Integrationsverfahren, das auch bei relativ unstetigen 
Funktionen und sogar bei Polstellen funktioniert (sofern das uneigentliche Integral exi¬ 
stiert)! 

• Beim Zeichnen der Funktionsgraphen schließlich werden automatisch die Achsen dem 
Bildschirm angepaßt. Das kennen Sie vielleicht. Aber es ist auch möglich, Funktionsscha- 
ren zu zeichnen, etwa einer Funktion und ihrer 1,2,... Ableitung. Ebenfalls möglich ist die 
Darstellung einer Funktionsschar in Abhängigkeit von Parametern, wie man es oft bei 
naturwissenschaftlichen Anwendungen benötigt. 

Die Abbildung zeigt den Plot von 

f a (x) = arctan(ax~4 - 8x 2 + 1) für a = 0,8,16,24. 
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Desk Eingeben Zeichnen 



Bild 5.1: Die Funktionenschar f(x,a) = arctan(a x ~4-8x +1) für a=0, 8 , 16 und 24 

Das Ganze wird trotz der Vielzahl der Features kein unleserliches Programmonster, denn 
Modula legt es nahe, alles in kleinen Portionen schön, eben modular zu programmieren. In 
den folgenden Abschnitten besprechen wir Einzelaufgaben und verpacken sie in getrennte 
Module: 

• Parser (mit Scanner) 

• Differenzierer 

• Optimiere!* 

• Mathelehrer (bringt dem System das Regelwerk bei) 

• Integrierer 

• Benutzereingaben (»User-Interface«) 

• Grafikausgabe 

Das Hauptprogramm ModPlot (=M0Dula-PL0T) ist dann entsprechend kurz. Bevor Sie wei¬ 
terlesen, sollten Sie das Programm unbedingt zunächst einmal laufen lassen. Es liegt auf der 
Diskette in übersetzter Form vor und kann vom Desktop aus gestartet werden. 

Interessant ist vielleicht noch, daß die wesentlichen Programmteile wie Parser, Differenzierer 
und Optimierer auf einem anderen Rechner entwickelt worden ist, was wieder einmal für die 










412 


Der Modul »Parser« 


gute Portabilität von Modula spricht. Lediglich die Benutzerschnittstellen wie Funktionsein¬ 
gabe, Ausgabe der Ableitung und des Integrals sind »Atari-spezifisch« mit GEM program¬ 
miert. Die Grafik-Ausgabe stützt sich auf unsere Module aus dem Kapitel 4. Im Bereich der 
Benutzerschnittstellen (Grafik, GEM-Aufrufe) wurden Megamax-spezifische Eigenheiten 
benutzt. Nur dieser Modul muß also bei Benutzung eines anderen Systems umgeschrieben 
werden. Sämtliche anderen Teile sind vollkommen portabel, da nur Standardprozeduren be¬ 
nutzt wurden. Aus diesem Grund haben wir auch einen kleinen String-Modul selbst geschrie¬ 
ben. Auch bei den mathematischen Funktionen gehen wir nicht über die gemeinsame Schnitt¬ 
menge der verschiedenen MathLibO-Funktionen hinaus. 

Bekanntlich gibt es keine »fertigen« Programme. Es gilt allenfalls der Spruch: »Ein fertiges 
Programm ist ein veraltetes Programm«. Vielleicht brauchen sie noch Wertetabellen, Nullstel¬ 
len, Polstellen oder Parameterdarstellung y(t) über x(t), wie bei Lissajous-Figuren. Alles ist 
durch die Modularisierung schön pflegeleicht, so daß man das Programm nach eigenen Vor¬ 
stellungen erweitern kann. 

Wenngleich unser Beispiel etwas theoriebeladen ist, da die Mathematik nicht jedermanns 
Hobby ist, so hoffen wir doch, ein Beispiel gefunden zu haben, was viel schönes Modula und 
etliche »Gags« zeigt. 


5.1 Der Modul »Parser« 

Wir erläutern die Funktionsweise des Programms am Beispiel der Funktion 
f(x) = x 2 *sin(x). 

Die Funktion wird zunächst eingegeben. Hierzu erscheint nach Anwahl des Menüpunktes 
»Funktion eingeben« erscheint die Dialogbox: 
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Bild 5.2: Dialogbox zur Funktionseingabe 

Die Box listet die implementierten Operatoren und Standardfunktionen auf. Folgende Ein¬ 
gabemöglichkeiten stehen also für die Beispielfunktion zur Verfügung: 

f(x) = x~2*sin x oder 

f(x) =x*x*sinx oder 
f(x) = sqr(x)*sin(x) O. ä. 

Wählen wir die erste Eingabemöglichkeit, so wird nach Schließen der Dialogbox - eventuell 
hat man vorher Definitions- oder Wertebereich geändert - die Prozedur parse aufgerufen. 
Sie erzeugt aus der Zeichenkette den Funktionsbaum auf der folgenden Seite: 

Dies besagt folgendes: Der Term ”X~2*SINX” ist ein Produkt (oberster Operator: »*«). 
Der erste Faktor ist eine Potenz (Operator: »~«), die Operanden sind X und 2. Der zweite 
Faktor besteht aus einer Funktion: SIN. Sie hat ein Argument: X. 
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Bild 5.3: Funktionsbaum x 2 sin x 

Die Knoten dieses Baumes zeigen auf den Varianten Verbund des Typs ParserNode (engl. 
node- »Knoten«). Die genaue Struktur geht aus dem Defmitionsmodul Parser hervor. 

DEFINITION MODULE Parser; 

CONST 

BezHIGH = 16-1; 

MaxHIGH = 255; 

TYPE RH = REAL; 

INDEX = CARDINAL; 

BezString = ARRAY[0..BezHIGH] OF CHAR; 

MaxString = ARRAY[0..MaxHIGH] OF CHAR; 

FunRl = PROCEDURE(RR): RR; (* Reelle, eindimensionale Funktion *) 

ErrorType = ( 


errOK, 

(* 

Kein Fehler *) 

errCharacter, 

(* 

unerlaubtes Zeichen im Text *) 

errBezeichner, 

(* 

undeklarierter Bezeichner *) 

errKlammerAuf, 

(* 

”(” erwartet *) 

errKlammerZu, 

(* 

”)” erwartet *) 

errKomma, 

(* 

”,” erwartet *) 

errAusdruck, 

(* 

Arithmetischer Ausdruck erwartet 
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errOperator (* Operator erwartet *) 

); 

SymType = ( 

Symünbekannt, SymEnde, 

KlammerAuf, KlammerZu, 

OpMinus, OpPlus, OpDurch, OpMal, OpHoch, OpNeg, 

SymPunRl, SymVarRR, SymKoRR); 

BezPtr = POINTER TO Bezeichner; 

Bezeichner = RECORD 
next: BezPtr; 

Name: BezString; 

CASE BezArt: SymType OP 

SymPunRl : Pktl : PunRl | 

SymVarRR : ValueRR : RR 1 
END END; 

ParserPtr = POINTER TO ParserNode; 

ParserNode = RECORD 

CASE OperArt: SymType OP 
OpNeg: 

Operand: ParserPtr | 

OpMinus, OpPlus, OpDurch, OpMal, OpHoch: 

Operandi, 0perand2: ParserPtr 1 
SymPunRl: 

BezPktl: BezPtr; 

Parameter: ParserPtr | 

SymVarRR: 

Variable: BezPtr | 

SymKoRR: 

KoRR: RR 

END END; 

VAR 

ScanZeile: MaxString; 

ScanPosition, ScanErrPos: CARDINAL; 

SyntaxError, ArithmeticError: BOOLEAN; 

ErrorArt: ErrorType; 

PROCEDURE HoleBezeichner(name: BezString): BezPtr; 

PROCEDURE LerneFunktion(name: BezString; Punktion: FunRl); 

PROCEDURE LerneVariable(name: BezString; VarWert: RR); 

PROCEDURE SetzeVariable(bez: BezPtr; wert: RR); 

PROCEDURE parse(zeile: ARRAY OP CHAR): ParserPtr; 

PROCEDURE BaumZuString(baum: ParserPtr; VAR formel: ARRAY OP CHAR); 
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PROCEDURE LoescheBaum(VAR bäum: ParserPtr); 

PROCEDURE NewNode(VAR node: ParserPtr); 

PROCEDURE berechne(bäum: ParserPtr; xWert: RR): RR; 

PROCEDURE PrinTree(p: ParserPtr); 

END Parser. 

Der Parser hat also die Aufgabe, den Funktionsterm als Zeichenkette »grammatikalisch« zu analy¬ 
sieren und - falls diese fehlerfrei ist - den entsprechenden Baum aufzubauen. Ansonsten wird die 
Fehlerposition zurückgegeben. Das Wort »Parser« leitet sich vom engl, to parse ab, was soviel heißt 
wie »zerteilen«. Gemeint ist »einen Satz nach seiner grammatikalischen Struktur zerlegen«. 

Der Modul Parserist der längste in diesem Programm. Seine Struktur gliedert sich wie folgt: 

1. Importliste. 

2. Lokaler Modul Scanner, der die Zeichenkette zeichenweise abgeht und die entsprechen¬ 
den Symbole erzeugt. 

3. Eigentlicher Parser; er baut den »Parserbaum« auf. 

4. Prozedur Berechne, die zu jedem übergebenen x-Wert aus dem Parserbaum den Funk¬ 
tionswert f(x) errechnet. 

5. Initialisierungsteil des Moduls Parser. 

Wir sehen hier die grobe Struktur wieder, die jedem Compiler zugrundeliegt: Scanner-Parser- 
Codegenerator. So funktioniert auch Ihr Modula-Compiler! Der Code-Erzeuger wandelt 
nämlich die vom Parser »vorverdauten« Textbausteine in 68000er-Code um, der Scanner hat 
den Text für den Parser »vorgekaut«. Er trennt die einzelnen Wörter (Bezeichner, Operatoren) 
voneinander und ordnet ihnen symbolische Namen zu. Der einzige Unterschied zu unserem 
Vorgehen besteht darin, daß kein echter Maschinencode erzeugt wird. Vielmehr wird aus dem 
Parserbaum mit einer Wertbelegung für die Variable x der Funktionswert f (x) in der Hoch¬ 
sprache errechnet. Es handelt sich also mehr um ein »interpretieren« des Parser-Baumes. 

Das MSM2-System liefert bereits eine fertige Prozedur Fctcomp im Modul Formelcompi¬ 
ler, die es gestattet, einen Funktionsstring sofort in Maschinencode zu übersetzen. Dies ist 
sehr komfortabel. Man benötigt den gesamten Modul Parser nicht, wenn man nur Funk¬ 
tionswerte ausrechnen will. Zudem ist die Berechnung sehr schnell, da echter Maschinencode 
erzeugt wird. Der Code wird zur Laufzeit erzeugt und auf dem Heap abgelegt. Bei einer Wert¬ 
ermittlung f (x) wird dieser Code einfach angesprungen und mit x abgearbeitet. 

Wenn sie also diesen Modula-Compiler besitzen, können Sie sehr schnell selbst ein eigenes 
Funktionenprogramm schreiben, wenn sie sich dabei auf die folgenden Themen beschränken: 
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• Erstellung einer Wertetabelle 

• Zeichnen von Funktionsgraphen 

• Ermittlung von Nullstellen, Minima und Maxima 

• numerisches Ableiten und Integrieren 

Unser Weg ist zwar sehr viel steiniger, hat aber zwei Vorteile: 

• Der gezeigte Parser ist auf allen Modula-Systemen einsetzbar. Da bei der Berechnung der 
Funktionswerte lediglich ein paar Zeiger übergeben werden, arbeitet es auch sehr rasant. 

• Der Parser-Baum gestattet auf einfache Weise die algebraische Ermittlung der Ableitung. 
Diese kann als Zeichenkette ausgegeben werden, was sehr viel leistungsstärker ist als das 
allgemein übliche Verfahren der numerischen Ableitung durch Annäherung durch Tan¬ 
gentensteigung. 

N un gehen wir auf die F unktionsweise des Moduls ein. Der eingegebene F unktionsstring, der für 
den Benutzer lesbar ist, muß also in einen Funktionsbaum (Parserbaum) umgewandelt werden, 
der für den Rechner handlich ist. Diese Aufgabe teilen sich im wesentlichen zwei Funktionsein¬ 
heiten: der Parser und der Scanner. Der Scanner sucht die eingegebene Zeichenkette nach zu¬ 
sammengehörenden Wörtern (Zahlen, Variablen- oder Funktionsnamen, 
Operationszeichen...) ab und liefert sie dem Parser in Form von Symbolen. Dabei werden Kon¬ 
stanten (die als Zeichenfolge vorliegen) in REAL-Zahlen umgewandelt. Erkennt der Scanner ei¬ 
nen Bezeichner (Kennzeichen: beginnt mit einem Buchstaben), sieht er über die Funktion 
HoleBezeichner in einer Liste (der BezeichnerListe) nach, ob der Bezeichner definiert ist. 

Der Parser wird über die Funktion parse mit dem Funktionsstring aufgerufen, parse 
übergibt mit StarteScanner die Zeichenkette an den Scanner, damit er sie sich global in 
der Variablen ScanZeile merken kann. Um Konflikte mit Groß- und Kleinschreibung zu 
vermeiden, wird der String zunächst einmal mit CopyCap kopiert und dabei in Großbuch¬ 
staben umgewandelt. Benötigt der Parser ein neues Symbol vom Scanner, ruft er die Funktion 
LiesSymbol auf. Anschießend findet er in dem Verbund ScanNode das nächste Symbol 
(vom Typ: SymType). 

Ein Term ist nicht einfach eine Reihung von Zahlen und Operatoren, sondern besitzt eine ge¬ 
wisse Struktur. Es gibt Operatoren, die einen Vorrang vor anderen haben (»*« bindet stärker 
als »+«). Zuerst müssen die Zahlen, die mit »~« verbunden sind, zuammengefaßt werden 
(»hoch« hat die höchste Priorität). Diese »Faktoren« werden durch »*« und »/« zu »Produk¬ 
ten« zusammengefaßt und diese wieder mit»+« und »- «(niedrigste Priorität) zu einer Summe. 
Auf der ersten Ebene haben wir also Plus und Minus. Das Vorzeichen und die Funktionen 
haben den stärksten Vorrang (auf der letzten Ebene). Zusätzlich bilden die Klammern weitere 
Gruppierungen. Das ganze läßt sich als Syntaxdiagramm darstellen: 
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Bild 5.4: Syntaxdiagramme des Parsers (Term, Summand, Faktor und Primary) 

Der Parser arbeitet vollkommen analog zu diesen Diagrammen. Jedes der vier Syntaxdia¬ 
gramme entspricht einer Prozedur Term, Summand, Faktor und Primary. Ein eckiger Kasten 
wird dabei in einen Aufruf der entsprechenden Funktion umgesetzt, ein runder in einen Aufruf 
des Scanners, der das jeweils nächste Symbol des Funktionsterms liefert. Ein vom Scanner ge¬ 
liefertes Symbol ist also für den Parser ein Terminalsymbol (vgl. Kapitel 1.1.3). Die Syntaxdia¬ 
gramme für Funktionsbezeichner, Variablenbezeichner und Konstante können zu¬ 
nächst noch Undefiniert bleiben. Der Parser arbeitet abstrakt mit ihnen; im Gesamt¬ 
system werden sie an späterer Stelle festgelegt. 
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Betrachten wir das Syntaxdiagramm »Term«. Ein »Term« besteht aus einem Summanden, 
dem beliebig oft »+« bzw. »-« ein weiterer Summand folgen kann. Für die Funktion Term 
bedeutet das folgendes: 

1. Summand einiesen (mit der Funktion Summand). 

2. Solange ein »+« oder »-«-Operator folgt, diesen Operator einiesen und einen weiteren 
Summanden lesen. 

Gleichzeitig muß natürlich der Parserbaum aufgebaut werden. Im einzelnen sieht das so aus: 

1. Term ruft Summand auf und erhält dabei einen Teilbaum für einen »Summanden«. 
Summand hat dabei aus dem Funktions-String einen kompletten »Summanden« gelesen. 

2. Nach dem Syntaxdiagramm kann nach einem Summanden ein »+« oder »-« folgen. Ist das 
nicht der Fall, besteht die »Summe« nur aus dem einzigen Summanden, den Term von 
Summand als Teilbaum erhalten hat. Diesen kann diese Funktion dann »Term« zurück¬ 
geben. 

3. Im anderen Fall liegt eine Summe oder Differenz vor, und Term muß dazu einen entspre¬ 
chenden Baum liefern. Dazu ruft Term jetzt BaueSymbol auf: diese Prozedur liest dazu 
den nächsten Operator ein (das »+« bzw.»-«) und erzeugt einen entsprechenden Knoten. 

4. Dieser Knoten benötigt zwei Teilbäume (Operandi und 0perand2) als Operanden. Den 
ersten hat Term zuvor von Summand erhalten. Den zweiten erhält Term durch einen 
weiteren Aufruf von Summand. 

5. Wenn dann kein weiteres »+« oder »-« folgt, kann dieser Knoten zurückgegeben werden. 
Ansonsten muß ein weiterer Summand angehängt werden. Dazu geht es weiter wie in 3. 

Wir sehen: Term liest einen kompletten »Term« ein und liefert einen Baum. Ebenso verfährt 
die Prozedur Summand; sie beschränkt sich im wesentlichen darauf, die Prozedur der nächsten 
Ebene aufzurufen: Faktor. 

Die Aufrufkette landet auf der untersten Ebene bei der Prozedur Pr i mary . Sie liest eine kleinst- 
mögliche Einheit - wie zum Beispiel eine Konstante oder Variable - ein. Leider Fiel uns hiefür 
kein geeigneter deutscher Bezeichner ein. Die verzweigte Struktur des Syntaxdiagrammes 
spiegelt sich in der CASE-Anweisung wieder. Wenn Primary eine öffnende Klammer »(« 
entdeckt, kann wieder ein kompletter Term folgen und es wird wieder Term aufgerufen. Die 
Struktur ist also eine Rekursion »im Kreis«, an der vier Prozeduren beteiligt sind: 

T e rm~ > Summand— >Fak t o r— >Pr i mar y— >T e rm... 

Wir sehen folgendes: Variablen, Konstanten, Funktionen und Klammern werden von der 
Prozedur Primary gelesen. Primary erzeugt dazu ein entsprechendes »Blatt« des Baumes. 
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Operatoren werden von einer Prozedur der entsprechenden Ebene gelesen. Es wird ein neuer 
Knoten erzeugt, dessen Teilbäume von Funktionen der niedrigeren Ebene geliefert werden. 

Dieses Beispiel reicht zum Verständnis des Parsers. Wenn sie Lust haben, können Sie den fol¬ 
genden Implementationsmodul durchgehen und es nacharbeiten. Beim Durchlesen des Quell¬ 
textes empfiehlt sich die oben genannte Gliederung 1.-5. des Parsers im »Hinterkopf« zu be¬ 
halten, dann wird es kein Problem mehr sein. 

IMPLEMENTATIONMODULE Parser; 

PROM SYSTEM IMPORT TSIZE; 

PROM Storage IMPORT ALLOCATE, DEALLOCATE; 

PROM MathLibO IMPORT power; 

PROM ZKetten IMPORT gleich; 

IMPORT ZKetten; 

( * = ==== ^ ====== ======= ===== = = ===== = = = === = ===: 

(*==================== Zeichen-Behandlung 

MODULE StringModul; 

EXPORT Ziffer, ReelleZiffer, Buchstabe, AlphaNura; 

PROCEDURE Ziffer(z: CHAR): BOOLEAN; 

BEGIN 

RETURN (”0” <= z) AND (z <= ”9”) 

END Ziffer; 

PROCEDURE Buchstabe(z: CHAR): BOOLEAN; 

BEGIN 

RETURN (”A” <= z) AND (z <= ”Z”) 

END Buchstabe; 

PROCEDURE AlphaNum(z: CHAR): BOOLEAN; 

BEGIN 

RETURN Ziffer(z) OR Buchstabe(z); 

END AlphaNum; 

END StringModul; 

*) 



( 
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PROCEDURE error(e: ErrorType); 

BEGIN 

IP e = errOK THEN SyntaxError : = EALSE; 

ErrorArt := errOK 

ELSE 

IP NOT SyntaxError THEN 
ErrorArt := e; 

SyntaxError := TRUE END 

END 

END error; 

(* ------—---- *) 

VAR 

BezeichnerListe: BezPtr; (* Liste aller Bezeichner (Punktionen) *) 

PROCEDURE HoleBezeichner(name: BezString): BezPtr; 

( * liefert zu einem Bezeichner-Namen einen Pointer auf den Bezeichner- 
* deskriptor, wenn er in der Bezeichnerliste steht, sonst NIL *) 

VAR p: BezPtr; 

BEGIN 

p : = BezeichnerListe; 

WHILE (p <> NIL) AND NOT gleich(p".Name, name) DO p := p".next END; 

RETURN p 

END HoleBezeichner; 

PROCEDURE LernePunktion( 
name: BezString; 
funk: FunRl); 

VAR 

neuer: BezPtr; 

BEGIN 

IP HoleBezeichner(name) <> NIL THEN HALT END; 

ALLOCATE(neuer, TSIZE(Bezeichner)); 
neuer".next := BezeichnerListe; 
neuer".Name := name; 
neuer".BezArt := SymFunRl; 
neuer".Pktl := funk; 

BezeichnerListe : = neuer 
END LernePunktion; 


(* schon definiert! *) 
(* Platz holen ... *) 
(* fuer Verkettung *) 
(* belegen... *) 


(* in die Liste einbauen *) 
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PROCEDURE LerneVariable( 
name: BezString; 
wert: RR); 

VAR 

neuer: BezPtr; 

BEGIN 

IP HoleBezeichner(name) <> NIL THEN HALT END; 

ALLOCATE(neuer, TSIZE(Bezeichner)); 

neuer A .next := BezeichnerListe; 

neuer".Name := name; 

neuer".BezArt := SymVarRR; 

neuer".ValueRR := wert; 

BezeichnerListe := neuer (* .. 

END LerneVariable; 

PROCEDURE SetzeVariable(bez: BezPtr; wert: RR); 

BEGIN 

IP bez = NIL THEN HALT END; 

IP bez".BezArt <> SymVarRR THEN HALT END; 
bez".ValueRR := wert 
END SetzeVariable; 

PROCEDURE ClearNode(VAR node: ParserNode); 

(* loescht einen ParserKnoten. Rein prophylaktische 
BEGIN 

WITH node DO 

CASE OperArt OP 

OpMinus, OpPlus, OpMal, OpDurch, OpHoch: 
Operandi := NIL; 

0perand2 := NIL | 

OpNeg: 

Operand := NIL | 

SymPunRl: 

Parameter := NIL | 

SymVarRR: 

Variable := NIL | 

ELSE 

(* NICHTS, nix zum loeschen da *) 

END 

END 

END ClearNode; 


(* schon definiert! *) 
(* Platz holen... *) 
(* Belegen ... *) 


. in die Liste einbauen *) 


(* muss Variable sein *) 


Angelegenheit *) 
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PROCEDURE BaumZuString(baum: ParserPtr; VAR formel: ARRAY OF CHAR); 
VAR 

s: ZKetten.StrRR; 
pos: INDEX; 
ueberlauf: BOOLEAN; 


PROCEDURE schreib(s: ARRAY OF CHAR); 

VAR i: INDEX; 

BEGIN 

i : = 0; 

WHILE NOT ueberlauf AND (i <= HIGH(s)) AND (s[i] <> OC) DO 
IF pos <= HIGH(formel) THEN 
formel[pos] := s[i]; 

INC(pos); INC(i) 

ELSE 

ueberlauf := TRUE 

END 

END 

END schreib; 


PROCEDURE wandle(p: ParserPtr; level: SymType); 
BEGIN WITH p~ DO 

IF OperArt < level THEN schreib(”(”) END; 
CASE OperArt OF 
OpNeg: 

schreib(”- ”); 

wandle(Operand, OpNeg) | 

OpMinus: 

wandle(Operandi, OpMinus); 

schreib (” - ”); 

wandle(0perand2,OpDurch) | 

OpPlus: 

wandle(Operandi, OpPlus); 

schreib(” + ”); 

wandle(0perand2, OpDurch) | 

OpDurch: 

wandle(Operandi, OpDurch); 

schreibt” / ”)> 

wandle(0perand2, OpHoch) | 

OpMal: 

wandle(Operandi, OpMal); 
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schreib(” * ”); 

wandle(0perand2, OpHoch) | 

OpHoch: 

wandle(Operandi, OpNeg); 

schreib(” '*»»); 

wandle(0perand2, OpHoch) | 

SymVarRR: 

schreib(Variable".Name) | 

SymFunRl: 

schreib(BezFktl~.Name); 
schreibe” ”); 

wandle(Parameter, OpNeg) j 
SymKoRR: 

ZKetten.RzuS(KoRR,3,s); schreibes) 

END; 

IF OperArt < level THEN schreibe”)”) END; 

END END wandle; 

BEGIN 

pos := 0; 

ueberlauf : = FALSE; 
wandle(bäum, SymEnde); 

IF pos <= HIGH(formel) THEN formel[pos] := OC END; 

IF ueberlauf THEN formel[HIGH(formel)] := ”#” END 
END BaumZuString; 

(*- 

: : nur zu Testzwecken: Ausgabe des kompletten Parser-Baumes 

*) 

PROCEDURE PrinTree(bäum: ParserPtr); 

VAR i,tiefe: CARDINAL; 

(*-Wird ausgeklammert, da er Ausgaben macht! ---> 

PROCEDURE printreel (p: ParserPtr); 

BEGIN 

WriteLn; 

FOR i := 1 TO tiefe DO WriteString(”. . |”) END; 

WriteString(”--”); 

IF p = NIL THEN 

WriteString(”*** NIL ***”) 

ELSE 


INC(tiefe); 
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CASE p~.OperArt OE 
OpNeg: 

WriteString(”(- (Neg))”); 
printreel(p~. Operand) | 

OpPlus, OpMinus, OpMal, OpDurch, OpHoch: 

CASE p~.OperArt OE 

OpPlus: WriteString(”[ + ] ”) | 

OpMinus: WriteString(”[-]”) | 

OpMal: WriteString(”[*]”) | 

OpDurch: WriteString(”[/]”) | 

OpHoch: WriteString(”[HOCH]”) 

END; 

printreel(p~.Operandi); 
printreel(p~.0perand2) | 

SymEunRl: 

WriteString(p y '. BezEktl". Name); WriteString(”(. )”); 
printreel(p~.Parameter) | 

SymVarRR: 

WriteString(p~.Variable".Name); WriteString( ” = ”); 
WriteReal(p~.Variable".ValueRR, 20,11) j 
SymKoRR: 

WriteReal(p~.KoRR, 20,11) 

END; 

DEC(tiefe) 

END 

END printreel; 

BEGIN 

tiefe := 0; 
printreel(bäum) 

<---—----Ende der Ausklammerung *) 

END PrinTree; 


* ================== 1. Teil: der Scanner ======================== *) 

MODULE Scanner; 

IMPORT 

gleich, Ziffer, ReelleZiffer, Buchstabe, AlphaNum, 

MaxHIGH, ScanZeile, ScanErrPos, Scanposition, 

ParserNode, SymType, BezString, BezPtr, HoleBezeichner, 

INDEX, RR, ClearNode, 

error, ErrorType, SyntaxError; 
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PROM ZKetten IMPORT CopyCAP, reell; 

EXPORT 

StarteScanner, LiesSymbol, ScanNode; 

VAR 

ScanNode: ParserNode; (* naechste Symbol vom Scanner *) 

ScanChar: CHAR; 

PROCEDURE LiesZeichen(): CHAR; 

VAR z: CHAR; 

BEGIN 

z := ScanChar; 

IP (ScanPosition <= MaxHIGH) AND (ScanZeile[ScanPosition] <>0C) THEN 
INC(ScanPosition); 

ScanChar := ScanZeile[ScanPosition] 

ELSE 

ScanChar := OC; (* Zeile zu Ende *) 

END; 

RETURN z 
END LiesZeichen; 

PROCEDURE SkipZeichen; 

VAR dummy: CHAR; 

BEGIN 

dummy := LiesZeichen(); 

END SkipZeichen; 

PROCEDURE LiesWort(VAR s: ARRAY OP CHAR); 

(* Liest genau ein Wort aus der ’ScanZeile’ nach ’s’ *) 

VAR 

i: INDEX; 
z: CHAR; 

BEGIN 

i : = 0; 

REPEAT 

z := LiesZeichen(); 

IP i <= HIGH(s) THEN s[i] := z; INC(i) END 
UNTIL NOT AlphaNum(ScanChar); 

IP i <= HIGH(s) THEN s[i] := OC END 
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END LiesWort; 

PROCEDURE LiesZahl; 

(* einiesen einer RR- Konstante *) 

VAR 

r, dlO: RR; 

BEGIN 

r : = 0.0; 

WHILE Ziffer(ScanChar) DO r : = 10.0 * r + 

FLOAT( 0RD(LiesZeichen()) - 0RD(”0”) ) END; 

IP ScanChar = ” THEN (* es kommen noch Nachkommastellen... *) 

SkipZeichen; 
dlO := 0.1; 

WHILE Ziffer(ScanChar) DO 

r : = r + PLOAT(ORD(LiesZeichen())-0RD(”0”)) * dlO; 
dlO := 0.1 * dlO END 

END; 

ScanNode.OperArt := SymKoRR; 

ScanNode. KoRR := r 
END LiesZahl; 

PROCEDURE LiesSymbol; 

(* 

* Liest aus der EingabeZeile ein Symbol und traegt es in ’ScanNode’ ein 

*) 

VAR 

BezName: BezString; 
bezei: BezPtr; 

BEGIN 

IP SyntaxError THEN HALT END; (* Parser nicht richtig gestoppt *) 

WHILE ScanChar = ” ” DO SkipZeichen END; 

ScanErrPos := ScanPosition; (* Position merken, falls Fehler auftritt *) 

IP Buchstabe (ScanChar) THEN (*-Bezeichner-*) 

LiesWort(BezName); 

bezei := HoleBezeichner(BezName); 

IP bezei = NIL THEN 

ScanNode.OperArt := SymUnbekannt; 
error(errBeZeichner) 

ELSE 

ScanNode. OperArt := bezei''. BezArt 

END; 

ClearNode(ScanNode); 
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CASE ScanNode.OperArt OE 
SymFunRl: 

ScanNode.BezEktl := bezei | 

SymVarRR: 

ScanNode.Variable : = bezei | 

Syraünbekannt: (* nix *) 

END 

ELSIE Zif fer (ScanChar) THEN (*-Konstante-* ) 

LiesZahl 


ELSE (* --- 

CASE ScanChar OE 

ScanNode.OperArt 
ScanNode.OperArt 
ScanNode.OperArt 
ScanNode.OperArt 
ScanNode.OperArt 
ScanNode. OperArt 
ScanNode.OperArt 
OC: ScanNode.OperArt 

ELSE 


sonst: Operator oder Satzzeichen - *) 

= KlammerAuf | 

= KlammerZu | 

= OpMinus | 

= OpPlus | 

= OpDurch | 

= OpMal | 

= OpHoch | 

= SymEnde (* Zeile zu Ende *) 


ScanNode.OperArt := SymUnbekannt; 
error(errCharacter) 

END; 

SkipZeichen; 


ClearNode(ScanNode) 

END; 

END LiesSymbol; 

PROCEDURE StarteScanner(VAR eingabe: 

(* - Initialisiert den Scanner 

BEGIN (* Reihenfolge Wichtig! *) 

CopyCAP(eingabe, ScanZeile); 
ScanErrPos : = 0; 

ScanPosition : = 0; 

ScanChar := ScanZeile[0]; 
error(errOK); 

LiesSymbol; 

END StarteScanner; 

END Scanner; 

(* ---- 


(* sicherheitshalber durchloeschen *) 


ARRAY OE CHAR); 

— *) 

(* Eingabe merken *) 
(* Startpositionen *) 

(* Erstes Zeichen Holen *) 
(* Fehler zuruecksetzen *) 
(* erstes Symbol einiesen *) 


PROCEDURE NewNode(VAR node: ParserPtr); 
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(* 

BEGIN 


Erzeugt einen neuen ParserNode 


ALLOCATE(node, TSIZE(ParserNode)); 
IP node = NIL THEN HALT END; 
node*.OperArt := SymUnbekannt; 


(* kein Speicher: brutal raus! *) 
(* sicherheitshalber *) 


END NewNode; 

PROCEDURE LoescheBaum(VAR p: ParserPtr); 

(* Loescht einen ParserBaum (gibt damit den Speicher wieder frei) *) 
BEGIN 

IF p <> NIL THEN 

CASE p".OperArt OF 


OpNeg: 

LoescheBaum(p~.Operand) | 

OpMinus, OpPlus, OpMal, OpDurch, OpHoch: 

LoescheBaum(p~.Operandi); 

LoescheBaum(p'\ 0perand2) | 

SymFunRl: 

LoescheBaum(p~.Parameter) | 

SymVarRR, SymKoRR: 

(* Nix, gibt keine UnterBaeume *) 

ELSE HALT (* da war wohl der Baum kaputt... *) 

END; 

DEALLOCATE(p, TSIZE(ParserNode)); 
p := NIL 


END 

END LoescheBaum; 

PROCEDURE SkipSymbol; 

BEGIN 

IF NOT SyntaxError THEN LiesSymbol END 
END SkipSymbol; 

PROCEDURE BaueSymbol(VAR nodePtr: ParserPtr); 

BEGIN 

IF SyntaxError THEN HALT END; (* Parser nicht richtig gestoppt *) 

NewNode(nodePtr); 
nodePtr“ : = ScanNode; 

LiesSymbol 
END BaueSymbol; 

PROCEDURE MussSymbol(ErwartetesSymbol: SymType; err: ErrorType); 

BEGIN 

IF ScanNode.OperArt = ErwartetesSymbol 
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THEN SkipSymbol 
ELSE error(err) 

END 

END MussSyrabol; 


(* 


2. der eigentliche Parser 


FORWARD makeTerm(): ParserPtr; 


*(” <Term> ”)” 


- •* 


<Primary>-*) 


PROCEDURE raakePrimary(): ParserPtr; 

VAR 

node: ParserPtr; 

BEGIN 

IF SyntaxError THEN RETURN NIL END; 

CASE ScanNode. OperArt OF 

KlammerAuf: (* -- 

SkipSymbol; 
node := makeTerm(); 

MussSyrabol(KlammerZu, errKlammerZu) | 

OpMinus: (* - 

BaueSyrabol(node); 

node".OperArt := OpNeg; (* das hier monadisch *) 

node". Operand := makePrimary() | 

SymFunRl: (* - <Bezeichner> <Priraary> - *) 

BaueSymbol(node); 

node".Parameter := makePrimary() | 

SymVarRR, SymKoRR: (* - Variable / Konstante - *) 

BaueSymbol(node) 

ELSE 

error(errAusdruck); 

RETURN NIL 

END; 

RETURN node; 

END makePrimary; 


PROCEDURE makeFaktor(): ParserPtr; 

VAR node, p: ParserPtr; 

BEGIN 

IF SyntaxError THEN RETURN NIL END; 
node := makePrimary(); 

IF ScanNode.OperArt = OpHoch THEN (* -- 


<Primary> <Faktor> - *) 
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BaueSymbol(p); 
p'“. Operandi := node; 
p~.0perand2 := makeFaktor(); 
node : « p END; 

RETURN node; 

END makeFaktor; 

PROCEDURE makeSummand(): ParserPtr; 

VAR 

node, p: ParserPtr; 

BEGIN 

IF SyntaxError THEN RETURN NIL END; 
node := makeFaktor(); 

LOOP 

IF SyntaxError THEN EXIT END; 

CASE ScanNode.OperArt OF 
OpMal, OpDurch: 

BaueSymbol(p); 
p~.Operandi := node; 
p~.0perand2 := makeFaktor(); 
node := p 
ELSE EXIT 
END 

END; 

RETURN node; 

END makeSummand; 

PROCEDURE makeTerm(): ParserPtr; 

VAR 

node,p: ParserPtr; 

BEGIN 

IF SyntaxError THEN RETURN NIL END; 
node := makeSummand(); 

LOOP 

IF SyntaxError THEN EXIT END; 

CASE ScanNode.OperArt OF 
OpPlus, OpMinus: 

BaueSymbol(p); 
p~.Operandi := node; 
p~.Operand2 := makeSummand(); 
node := p 
ELSE EXIT; 
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END 

END; 

RETURN node; 

END makeTerm; 

PROCEDURE parse(EingabeZeile: ARRAY OE CHAR): ParserPtr; 
VAR node: ParserPtr; 


BEGIN 

StarteScanner(EingabeZeile); 
node : = makeTerm(); 

PrinTree(node); 

IF ScanNode.OperArt <> SymEnde THEN 
error(errOperator); 
LoescheBaum(node) END; 

RETURN node 
END parse; 


(* Scanner initialisieren *) 
(* Einen Term abholen *) 


(* Fehler = = > Baum wieder abbauen *) 




3. der Rechner (berechnet den Baum) 


VAR VarX: BezPtr; 


PROCEDURE eval(p: ParserPtr): RR; 

CONST 

schrott = 88S.888; 

VAR 

temp: RR; 

BEGIN 

IE p = NIL THEN HALT END; (* Da ist wohl der Baum nicht vollstaendig *) 
IE ArithmeticError THEN RETURN schrott END; (* Bei Fehler: Ungueltig *) 
CASE p~.OperArt OE 
OpNeg: 

RETURN - eval(p~.Operand) | 

OpPlus: 

RETURN eval(p~.Operandi) + eval(p~.0perand2) | 

OpMinus: 

RETURN eval(pl. Operandi) - eval(p~.0perand2) | 

OpMal: 

RETURN eval(p".Operandi) * eval(p~. Operand2) | 

OpDurch: 

temp := eval(p“.Operandß); (* Divisor zuerst berechnen ... *) 

IE temp =0.0 THEN (* Division durch Null abfangen *) 
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ArithmeticError : = TRUE; RETURN schrott END; 

RETURN eval(p~.Operandi) / temp | 

OpHoch: 

temp := eval(pOperandi); 

IE temp <= 0.0 THEN (* negative Basis abfangen * ) 

ArithmeticError := TRUE; 

RETURN schrott END; 

RETURN power(temp,eval(p~. 0perand2)) ) 

SymEunRl: 

RETURN p~. BezEktl Ä . Ektl ( eval(p-. Parameter) ) | 

SymVarRR: 

RETURN p'*. Variable''. ValueRR | 

SymKoRR: 

RETURN p'-.KoRR 

ELSE HALT (* Baum defekt *) 

END 

END eval; 


PROCEDURE berechne(bäum: ParserPtr; xWert: RR): RR; 
BEGIN 


SetzeVariable(VarX, xWert); 
ArithmeticError := EALSE; 
RETURN eval(bäum) 

END berechne; 


(* noch ist alles OK. 


0 


Modul-Initialisierung 


BEGIN 

BezeichnerListe : = NIL; 
LerneVariable(”X”,0.0); 

VarX := HoleBezeichner(”X”); 
END Parser. 


Der Parser und die Benutzerschnittstelle brauchen einige Stringprozeduren. Wir gehen hier 
einmal nicht den üblichen Weg des Imports aus Systemmodulen, sondern schreiben eigene, 
auf unsere Zwecke zielende Routinen. Vielleicht ist es für den Leser ganz interessant, wie man 
so etwas macht. Natürlich sind sie in einem eigenen externen Modul verpackt: 









434 


Der Modul »Parser« 


DEFINITION MODULE ZKetten; 


TYPE 


RR = REAL; (* REAL oder LONGREAL *) 

StrRR = ARRAY[0..15] OF CHAR; 

INDEX = CARDINAL; (* Bei manchen Compilern: INTEGER *) 


PROCEDURE gleich(VAR sl,s2: ARRAY OF CHAR): BOOLEAN; 
PROCEDURE CopyCAP(VAR quelle, ziel: ARRAY OF CHAR); 

PROCEDURE reell(str: ARRAY OF CHAR; VAR ok: BOOLEAN): RR; 
PROCEDURE card (str: ARRAY OF CHAR): CARDINAL; 

PROCEDURE RzuS(r: RR; n: CARDINAL; VAR str: ARRAY OF CHAR); 
PROCEDURE CzuS(c: CARDINAL; VAR str: ARRAY OF CHAR); 

END ZKetten. 


IMPLEMENTATION MODULE ZKetten; 

IMPORT Strings, StrConv; 

PROCEDURE gleich(VAR sl,s2: ARRAY OF CHAR): BOOLEAN; 

VAR i: INDEX; 

BEGIN 

(* - eigene Version: lahm, läuft aber fast überall - *) 

i : = 0; 

WHILE (i <= HIGH(sl)) AND (i <= HIGH(s2)) 

AND (sl[i] = s2[i]) 

AND (sl[i] <> OC) AND (s2[i] <> OC) DO 
INC(i) 

END; 

RETURN ((i > HIGH(sl)) OR (sl[i] = OC)) AND ((i > HIGH(s2)) OR (s2[i] = OC)) 

(* -- Version Hänisch- SPC- TDI-Modula -> 

RETURN Strings.Compare(sl, s2) =0 *) 

(* - Version Megamax-Modula -> 

RETURN Strings. Compare(a,b) = Strings.equal *) 

END gleich; 

PROCEDURE CopyCAP(VAR quelle, ziel: ARRAY OF CHAR); 

(* Wandelt String 'quelle’ in GROSSBUCHSTABEN nach ’ziel’ um *) 

VAR i: INDEX; 

BEGIN 

i : = 0; 
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WHILE (i <= HIGH(quelle)) AND (i <= HIGH(ziel)) AND (quelle[i] <> OC) DO 
ziel[i] := CAP(quelle[i]); 

INC(i) END; 
ziel[i] : = OC 
END CopyCAP; 

PROCEDURE reell(str: ARRAY OF CHAR; VAR ok: BOOLEAN): RR; 

VAR pos: INDEX; 

BEGIN 

pos := 0; 

RETURN StrConv.StrToReal(str, pos, ok); 

END reell; 

PROCEDURE card(str: ARRAY OF CHAR): CARDINAL; 

VAR pos: INDEX; ok: BOOLEAN; 

BEGIN 

pos := 0; 

RETURN StrConv.StrToCard(str, pos, ok) 

END card; 

PROCEDURE RzuS(r: RR; n: CARDINAL; VAR str: ARRAY OF CHAR); 

VAR ss: Strings.String; ok: BOOLEAN; 

BEGIN 

ss := StrConv. RealToStr(r, 15, n); 

Strings.Assign(ss, str, ok) 

END RzuS; 

PROCEDURE CzuS(c: CARDINAL; VAR str: ARRAY OF CHAR); 

VAR ss: Strings.String; ok: BOOLEAN; 

BEGIN 

ss := StrConv.CardToStr(c,5); 

Strings.Assign(ss, str, ok) 

END CzuS; 


END ZKetten. 
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5.2 Der Modul »Differenzierer» 

Hier geht es um das algebraische Ableiten. Unsere Beispielfunktion f(x) mit dem 
Funktionsterm ”x~2 *sin x” soll also die Zeichenkette für Ableitung 
f’ (x)=2 * X * SIN X + X~2 * COS X” werden. Der Definitionsmodul enthält nur 
zwei Prozeduren: 

DEFINITION MODULE Differenzierer; 

FROM Parser IMPORT ParserPtr, BezString; 

VAR 

DifferError: BOOLEAN; 

PROCEDURE LerneAbleitung(StrFkt: BezString; StrAbleit: ARRAY OF CHAR); 

PROCEDURE Ableitung(bäum: ParserPtr): ParserPtr; 

END Differenzierer. 


Wie funktioniert nun das Ableiten im einzelnen? 

Zunächst wird der Prozedur Ableitung unsere Funktion als Parserbaum übergeben. Mit 
diesem Baum ruft man die Prozedur di ff auf, die die eigentliche Arbeit macht. Wenn Sie sich 
di ff weiter unten im abgedruckten Implementationsmodul ansehen, erkennen Sie, daß hier 
nur folgende Ableitungsregeln implementiert sind: 


1. 

(-f)’ 

= -f’ 

2. 

(f+gr 

öß 

+ 

Li 

II 

3. 

(f-gr 

bO 

I 

L 

ii 

4. 

(f*g)’ 

= f ’ *g+f*g J 

5. 

(f/g)’ 

=(g*f’-g’*f)/(g*g) 

6a. 

(f-g)’ 

= (f~g)*(g’*LN(f) + g*fVf) 

6b. 

(f-k)> 

=k*f~(k-l) k konstant 

7a. 

x> 

= 1 

7b. 

k’ 

=0 k konstant 

8. 

(f(g(x))’ 

=f’ (g(x))*g’(X) 


In den Fällen 1 -6a. wird die Bildung der Ableitung lediglich durch ein bis zwei Selbstaufrufe 
erledigt (Rekursion). Für den Fall 6a wird also die Logarithmusfunktion gebraucht. Für den 
Fall 8 muß für vordefinierte Funktionen die Ableitung bekannt sein. Zum Beispiel 
sin , = cos. Hierzu wird in der Prozedur LerneAbleitung die ListeDerAbleitungen 
durchsucht. 
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Im einzelnen wird aus unserem Beispielbaum: 



Bild 5.5: Funktionsbauin x sin x 

Der Differenzierer macht daraus folgenden Baum: 



Bild 5.6: Funktionsbauin der nicht optimierten Ableitungsfunktion 
F (x) = (2* l)*(x''(2- l))*sin x + x~2*(l*cos x) 
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Dieser Baum entspricht dem Term (2*l)*(x~(2-l))*sin x +x~2*(l*cos x) für die Ablei¬ 
tungsfunktion. 

Dies ist sicherlich noch nicht die optimale Form 

2 * X * SIN X + X ~ 2 * COS X, 

weshalb noch ein »Optimierer« nachgeschaltet wird, um den Term zu kürzen. Doch zunächst 
zum Implementationsmodul Differenzierer: 


IMPLEMENTATION MODULE Differenzierer; 

PROM SYSTEM IMPORT TSIZE; 

PROM Parser IMPORT 

SymType, RR, PunRl, BezString, BezPtr, ParserPtr, 
parse, NewNode, SyntaxError, HoleBezeichner, LoescheBaum; 

FROM Optimierer IMPORT IsX, konstant, Optimiere, BaumCopy, ErsetzeCopy; 

PROM Storage IMPORT ALLOCATE; 

TYPE 

DifferPtr = POINTER TO Differ; 

Differ = RECORD 

next: DifferPtr; 

Punktion: BezPtr; 

Ableitung: ParserPtr END; 


VAR 


ListeDerAbleitungen: DifferPtr; 
LnPunktion: BezPtr; 


(* fürs Ableiten von a~b *) 
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PROCEDURE LerneAbleitung(StrFkt: BezString; StrAbleit: ARRAY OP CHAR); 

VAR 

fkt: BezPtr; 
d: ParserPtr; 
r: DifferPtr; 

BEGIN 

fkt := HoleBezeichner(StrPkt); 

IP fkt = NIL THEN HALT END; (* Punktion nicht bekannt *) 

IP fkt~.BezArt <> SymPunRl THEN HALT END; (* keine Punktion *) 

d := parse(StrAbleit); 

IP SyntaxError THEN HALT END; 

ALLOCATE(r, TSIZE(Differ)); 

r~.next := ListeDerAbleitungen; (* in die Liste eintragen *) 

r~.Punktion := fkt; 
r~.Ableitung := d; 

ListeDerAbleitungen := r 
END LerneAbleitung; 

PROCEDURE HoleAbleitung(fkt: BezPtr): ParserPtr; 

(* - sucht die Ableitung einer Funktion aus der Liste - *) 

VAR r: DifferPtr; 

BEGIN 

r := ListeDerAbleitungen; 

WHILE (r <> NIL) AND (r~. Punktion <> fkt) DO r : = rLnext END; 

IP r = NIL THEN RETURN NIL ELSE RETURN r~.Ableitung END; 

END HoleAbleitung; 

PROCEDURE operator(op: SymType; a,b:ParserPtr): ParserPtr; 

VAR p: ParserPtr; 
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BEGIN 

NewNode(p); 
p~.OperArt := op; 
p".Operandi := a; 
p~.0perand2 := b; 

RETURN p; 

END operator; 

PROCEDURE plus(a,b:ParserPtr): ParserPtr; 

BEGIN 

RETURN operator(OpPlus, a,b) 

END plus; 

PROCEDURE minus(a,b:ParserPtr): ParserPtr; 

BEGIN 

RETURN operator(OpMinus, a,b) 

END minus; 

PROCEDURE mal(a,b: ParserPtr): ParserPtr; 

BEGIN 

RETURN operator(OpMal, a, b); 

END mal; 

PROCEDURE durch(a,b: ParserPtr): ParserPtr; 

BEGIN 

RETURN operator(OpDurch, a,b) 

END durch; 

PROCEDURE hoch(a,b: ParserPtr): ParserPtr; 

BEGIN 

RETURN operator(OpHoch, a,b) 

END hoch; 

PROCEDURE BaueLn(a: ParserPtr): ParserPtr; 

VAR p: ParserPtr; 

BEGIN 

IP LnPunktion = NIL THEN LnEunktion := HoleBezeichner(”LN”) END; 
IP LnPunktion = NIL THEN (* Eine Punktion ”LN” muß da sein !!! *) 
DifferError := TRUE; 

RETURN NIL 
ELSE 

NewNode(p); 

p".OperArt := SymPunRl; 
p~.BezFktl := LnPunktion; 
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p~.Parameter := a; 

RETURN p 

END 

END BaueLn; 

PROCEDURE konst(x:RR): ParserPtr; 

VAR p: ParserPtr; 

BEGIN 

NewNode(p); 

p~.0perArt SymKoRR; 
p~. KoRR : = x; 

RETURN p 
END konst; 

PROCEDURE diff(p: ParserPtr): ParserPtr; 

VAR d: ParserPtr; 

BEGIN 

IE DifferError THEN RETURN NIL END; 

WITH p~ 

DO CASE OperArt OP 
OpNeg: 

RETURN minus(konst(0.0), diff(Operand)) | 

OpMinus: 

RETURN minus(diff(Operandi), diff(0perand2)) | 

OpPlus: 

RETURN plus(diff(Operandi), diff(0perand2)) | 

OpMal: 

(* — f(/g)* = (f’*g - f*g* )/(g*g) *) 

RETURN plus( 

mal(diff(Operandi), BaumCopy(0perand2)), 
mal(BaumCopy(Operandi), diff(0perand2))) | 

OpDurch: 

(* --- f(*g)’ = f**g + f # g’ --- *) 

RETURN durch( 
minus ( 

mal(diff(Operandi), BaumCopy(0perand2)), 
mal(BaumCopy(Operandi), diff(0perand2))), 
mal (BaumCopy(0perand2), BaumCopy(0perand2)) 

) I 

OpHoch: 

d := BaumCopy(0perand2); 

Optimiere(d); 

IE konstant(d) THEN 

(*-(f Ä k) # = k*f* * f^(k-l)-*) 
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RETURN mal( 

mal(d, diff(Operandi)), 
hoch( 

BaumCopy(Operandi), 

minus(BaumCopy(d), konst(l.O)) 

) ) 

ELSE 

(*-(f~g)’ = f*g * (g’*ln f + g*f»/f). -*) 

RETURN mal( 

hoch(BaumCopy(Operandi), BaumCopy(d)), 
plus ( 

mal(di ff(d),BaueLn(BaumCopy(Operandi))), 
durch(mal(d, diff(Operandi)), 

BaumCopy(Operandl)) 

) ) 

END | 

SymKoRR, SymVarRR: 

IE IsX(p) 

THEN RETURN konst(l.O) 

ELSE RETURN konst(0,0) END | 

SymEunRl: 

d := HoleAbleitung(BezEktl); 

IE d = NIL THEN 

DifferError := TRUE; 

RETURN NIL 

ELSE 

RETURN mal(di ff(Parameter), ErsetzeCopy(d, Parameter)) 

END 

ELSE 

DifferError := TRUE; 

RETURN NIL 

END 

END 

END diff; 

PROCEDURE Ableitung(bäum: ParserPtr): ParserPtr; 

VAR d: ParserPtr; 

BEGIN 

IE bäum = NIL THEN HALT END; 

DifferError := PALSE; 
d := diff(bäum); 

IE DifferError THEN 
LoescheBaum(d) 
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ELSE 

Optimiere(d) 

END; 

RETURN d 
END Ableitung; 

BEGIN 

ListeDerAbleitungen := NIL; 
LnEunktion : = NIL 
END Differenzierer. 


5.3 Der Modul »Optimierer« 

Wie erwähnt, soll der Optimierer den aus dem Differenzierer erhaltenen Baum nacharbeiten, 
so daß der Funktionsstring etwas gefälliger wird und schneller zu berechnen ist. Zum Beispiel 
soll aus dem Term »1. 0+2. 0« der Term »3.0« oder aus »l.0*x« kurz X gemacht 
werden. Hierzu sind verschiedene Regeln anzuwenden und auszuprobieren, ob es sich wirk¬ 
lich um eine Vereinfachung handelt. 

Das System muß dazu erst einmal die Vereinfachungsregeln lernen. Zur Aufnahme dieser 
Regeln dient der im nächsten Abschnitt besprochene Modul MatheLehrer, der Möglichkeit 
bietet, dem System beliebige weitere Regeln beizubringen. Hier handelt es sich also um ein 
Programm der »Künstlichen Intelligenz«. 

Doch zurück zum Optimierer. Die Regeln sind also schon vorgegeben, sie müssen also 
»gelernt« und angewandt werden. Der Definitionsmodul lautet: 

DEEINITION MODULE Optimierer; 

PROM Parser IMPORT ParserPtr; 

TYPE 

UmformungPtr = POINTER TO Umformung; 

Umformung = RECORD 

next: UmformungPtr; 
alt,neu: ParserPtr 

END; 

PROCEDURE LerneRegel(StrAlt, StrNeu: ARRAY OP CHAR); 

PROCEDURE BaumGleich(bl,b2: ParserPtr): BOOLEAN; 

PROCEDURE BaumCopy(alt: ParserPtr): ParserPtr; 
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PROCEDURE ErsetzeCopy(alt: ParserPtr; ex: ParserPtr): ParserPtr; 
PROCEDURE IsX(node: ParserPtr): BOOLEAN; 

PROCEDURE konstant(node: ParserPtr): BOOLEAN; 

PROCEDURE Optimiere(VAR bäum: ParserPtr); 

END Optimierer. 


Zur Erläuterung greifen wir wieder unser Beispiel auf. Es ging um die Ableitung der Funktion f(x) = 
x 2 -sin x. Der Differenzierer erstellte hieraus einen Baum, der dem Term (2*1) *(x~(2-l)) 
*sin x + x~2* (l*cos x) entspricht. Der Optimierer baut hieraus nun folgenden Baum auf: 



Dieser Baum entspricht nun dem String 2*x*sin x + sqr(x)*cos x, wie man sich das 
wünscht. 

Hier der Implementationsmodul: 

IMPLEMENTATION MODULE Optimierer; 


EROM SYSTEM IMPORT TSIZE; 

PROM Storage IMPORT ALLOCATE, DEALLOCATE; 
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FROM Parser IMPORT 

ParserPtr, SymType, NewNode, LoescheBaum, ArithmeticError, 
berechne, BezPtr, parse, 

HoleBezeichner, RR, SyntaxError, PrinTree; 

VAR 

ListeDerRegeln: UmformungPtr; 

Optimierungwiederholen: BOOLEAN; 

X: BezPtr; 

PROCEDURE konstant(node: ParserPtr): BOOLEAN; 

BEGIN 

CASE node".OperArt OF 
SymKoRR: 

RETURN TRUE 

ELSE 

RETURN FALSE 

END 

END konstant; 

PROCEDURE IsX(node: ParserPtr): BOOLEAN; 

BEGIN 

RETURN (node".OperArt = SymVarRR) AND (node".Variable = X) 
END IsX; 

PROCEDURE SetzeKonstant(VAR node: ParserPtr); 

VAR hw: RR; 

BEGIN 

hw := berechne(node,999. 999); 

LoescheBaum(node); 

NewNode(node); 

node".OperArt := SymKoRR; 

node".KoRR : = hw; 

Optimierungwiederholen := TRUE 
END SetzeKonstant; 

PROCEDURE BaumCopy(alt: ParserPtr): ParserPtr; 

VAR 

neu: ParserPtr; 

BEGIN 

IF alt = NIL THEN HALT END; 

NewNode(neu); 

neu".OperArt := alt".OperArt; 

CASE alt". OperArt OF 
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OpNeg: 

neu". Operand := BaumC opy( alt". Operand) | 

OpMinus, OpPlus, OpDurch, OpMal, OpHoch: 

neu".Operandi := BaumCopy(alt". Operandi); 
neu".0perand2 := BaumCopy(alt". Operand2) | 

SymKoRR, SymVarRR: 

neu" :» alt" | 

SymFunRl: 

neu".BezFktl := alt".BezFktl; 

neu".Parameter := BaumCopy(alt". Parameter) 

END; 

RETURN neu 
END BaumCopy; 

(* Kopie mit einsetzen von ’ex’ in ’alt’ ---*) 

PROCEDURE ErsetzeCopy(alt: ParserPtr; ex: ParserPtr): ParserPtr; 
VAR neu: ParserPtr; 

BEGIN 

IP alt = NIL THEN HALT END; 

IP IsX(alt) THEN RETURN BaumCopy(ex) END; 

NewNode(neu); 

neu".OperArt := alt".OperArt; 

CASE alt".OperArt OP 
OpNeg: 

neu".Operand := ErsetzeCopy(alt". Operand, ex) | 
OpMinus, OpPlus, OpDurch, OpMal, OpHoch: 

neu". Operandi := ErsetzeCopy(alt". Operandi, ex); 
neu".0perand2 := ErsetzeCopy(alt". 0perand2, ex) | 
SymFunRl: 

neu".BezFktl := alt".BezFktl; 

neu".Parameter := ErsetzeCopy(alt". Parameter, ex) | 
SymKoRR, SymVarRR: 
neu" := alt" 

END; 

RETURN neu 
END ErsetzeCopy; 

PROCEDURE 0pGleich(nl,n2: ParserPtr): BOOLEAN; 

BEGIN 

IP nl".OperArt = n2".OperArt THEN 
CASE nl".OperArt OF 
SymFunRl: 

RETURN nl".BezFktl = n2".BezFktl | 

SymKoRR: 
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RETURN nl".KoRR = n2".KoRR | 

SymVarRR: 

RETURN nl".Variable = n2".Variable 
ELSE RETURN TRUE 
END 

ELSE 

IE konstant(nl) AND konstant(n2) THEN 

RETURN berechne(nl,123.456) = berechne(n2,321.654) 

ELSE 

RETURN PALSE 

END 

END 

END OpGleich; 

PROCEDURE BaumGleich(bl,b2: ParserPtr): BOOLEAN; 

BEGIN 

IE bl = NIL THEN HALT END; 

IE b2 = NIL THEN HALT END; 

IE NOT 0pGleich(bl,b2) THEN RETURN EALSE END; 

CASE bl".OperArt OE 
OpNeg: 

RETURN BaumGleich(bl".Operand, b2".Operand) | 

OpPlus, OpMal: (* - kommutative Operatoren - *) 

RETURN (BaumGleich(bl".Operandi, b2".Operandi) 

AND BaumGleich(bl".0perand2, b2".0perand2)) 

OR (BaumGleich(bl".Operandi, b2".0perand2) 

AND BaumGleich(bl". 0perand2, b2".0perand2)) | 

OpMinus, OpDurch, OpHoch: 

RETURN BaumGleich(bl".Operandi, b2".Operandi) 

AND BaumGleich(bl".Operand2, b2".0perand2) | 

SymPunRl: 

RETURN BaumGleich(bl".Parameter, b2".Parameter) 

ELSE 

RETURN TRUE 

END 

END BaumGleich; 

(* versucht, eine Regel aus der Liste anzuwenden-*) 

PROCEDURE NutzeRegel(VAR formel: ParserPtr; alt, neu: ParserPtr); 

VAR PormX: ParserPtr; 

PROCEDURE TesteRegel(bäum, vgl: ParserPtr): BOOLEAN; 

BEGIN 

IE IsX(vgl) THEN 
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IF FormX = NIL 

THEN FormX := bäum; RETURN TRUE 
ELSE RETURN Baumöleich(bäum, FormX) 

END 

ELSE 

IF OpGleich(bäum, vgl) THEN 
CASE bäum*'. OperArt OF 
OpNeg: 

RETURN TesteRegel(bäum". Operand, vgl".Operand) j 

OpPlus, OpMal: (* - kommutative Operatoren - *) 

RETURN (TesteRegel(bäum".Operandi, vgl". Operandi) 

AND TesteRegel(bäum". 0perand2, vgl" . 0perand2)) 

OR (TesteRegel(baum". Operandi, vgl".0perand2) 

AND TesteRegel(baum". 0perand2, vgl". Operandi)) 1 
OpMinus, OpDurch, OpHoch: 

RETURN TesteRegel(bäum" . Operandi, vgl".Operandi) 

AND TesteRegel(bäum". 0perand2, vgl".0perand2) j 
SymFunRl: 

RETURN TesteRegel(bäum". Parameter, vgl". Parameter) 

ELSE 

RETURN TRUE 

END 

ELSE 

RETURN FALSE 

END 

END 

END TesteRegel; 

BEGIN (* NutzeRegel *) 

FormX := NIL; 

IF TesteRegel(formel, alt) THEN 

IF FormX <> NIL THEN FormX := BaumCopy(FormX) END; 

LoescheBaum(formel); (* ...hier geloescht werden *) 

formel := ErsetzeCopy(neu, FormX); 

IF FormX <> NIL THEN LoescheBaum(FormX) END; 

Optimierungwiederholen := TRUE 

END 

END NutzeRegel; 

(* alle Regeln durchprobieren-*) 

PROCEDURE ProbiereRegeln(VAR bäum: ParserPtr); 

VAR 

up: UmformungPtr; 
altbaum: ParserPtr; 
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BEGIN 

REPEAT 

altbaum := bäum; 
up := ListeDerRegeln; 

WHILE up <> NIL DO 

NutzeRegel(baum, up".alt, up".neu); 
up := up".next 

END 

UNTIL altbaum = bäum (* bis keine Regel mehr angewendet wurde *) 

END ProbiereRegeln; 

PROCEDURE optimize(VAR bäum: ParserPtr); 

BEGIN 

REPEAT 

IP ArithmeticError THEN RETURN END; 

(* - zuerst die UnterBaeume Optimieren - *) 

WITH bäum" DO 

CASE bäum''. OperArt OP 
OpNeg: 

optimize(Operand) | 

OpMinus, OpPlus, OpDurch, OpMal, OpHoch: 
optimize(Operandl); 
optimize(Operand2) | 

SymPunRl: 

optimize(Parameter) 

ELSE 

(* NIX, die anderen haben keine Unterbaeume *) 

END 

END; 

Optimierungwiederholen := PALSE; 

ProbiereRegeln(baum); 

(•* - konstante Ausdruecke berechnen - *) 

CASE bäum".OperArt OP 
OpNeg: 

IP konstant(bäum".Operand) THEN SetzeKonstant(bäum) END i 
OpMinus, OpPlus, OpDurch, OpMal, OpHoch: 

IP konstant(bäum".Operandi) AND konstant(bäum". 0perand2) THEN 
SetzeKonstant(bäum) 

END | 

SymPunRl: 

IP konstant(bäum".Parameter) THEN 
SetzeKonstant(bäum) 


ELSE 


END 
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(* Nix *) 

END; 

UNTIL NOT Optimierungwiederholen; 

END optimize; 

PROCEDURE Optimiere(VAR f: ParserPtr); 

BEGIN 

ArithmeticError := EALSE; 
optimize(f); 

IE ArithmeticError THEN LoescheBaum(f) END 
END Optimiere; 

PROCEDURE LerneRegel(StrAlt, StrNeu: ARRAY OE CHAR); 

VAR regel: UmformungPtr; 

BEGIN 

ALL0CATE(regel, TSIZE(Umformung)); 
regel". next := ListeDerRegeln; 

regel".alt := parse(StrAlt); IE SyntaxError THEN HALT END; 
regel".neu := parse(StrNeu); IF SyntaxError THEN HALT END; 
ListeDerRegeln := regel 
END LerneRegel; 

BEGIN 

X := HoleBezeichner(”X”); 

ListeDerRegeln := NIL; 

END Optimierer. 
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5.4 Künstliche Intelligenz mit Modula: 
der Modul »MatheLehrer« 

Der Definitionsmodul ist von überraschender Kürze: 

DEFINITION MODULE MatheLehrer; 

END MatheLehrer. 

Es handelt sich also um eine reine Initialisierung. In MatheLehrer sind sämtliche Zuordnun¬ 
gen von Strings und den entsprechenden mathematischen Funktionen - wie ”SIN” zu sin- 
in der Prozedur LehreFunktionen enthalten. Sie können diese Liste jederzeit mit eigenen 
Funktionen erweitern. Bei einer Erweiterung sollte auch der Prozedur LehreAbleitungen 
der Term der Ableitung hinzugefügt werden, sonst kann der Differenzierer diese Funktion 
nicht behandeln. Anschließend brauchen sie lediglich das Programm neu zu kompilieren, und 
schon können Sie die neue Funktion in einem Term benutzen. 

MatheLehrer stellt nicht nur die Funktionszuordnungen für den Parser und die Ableitungs¬ 
zuordnungen für den Differenzierer bereit, sondern lehrt auch dem Optimierer, was er be¬ 
rücksichtigen soll. Hierzu wird eine Liste von Vereinfachungsregeln in der Prozedur Lehre- 
Regeln aufgelistet. Auch dieser Satz von Regeln ist beliebig erweiterbar. Der MatheLehrer 
lernt also von Ihnen (Professor) neue Regeln und kann sie dann an Parser, Optimierer und Dif¬ 
ferenzierer (Schüler) weitergeben. Bisjetzt sind folgende Variablen-und Funktionsbezeichner 
implementiert: 
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Bild 5.8: Syntaxdiagramme für Funktionsbezeichner , Variablenbezeichner und Konstante 
Schauen Sie sich unbedingt den Implementationsmodul an, er ist ganz einfach aufgebaut! 
IMPLEMENTATION MODULE MatheLehrer; 

PROM MathLibO IMPORT sin, cos, arctan, ln, exp, sqrt; 

PROM Parser IMPORT ArithmeticError, LernePunktion,LerneVariable, RR; 

PROM Optimierer IMPORT LerneRegel; 

PROM Differenzierer IMPORT LerneAbleitung; 
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CONST schrott = 888.888; (* ein ”undefiniertes” Ergebnis *) 

PROCEDURE UnserTan(x: RR): RR; 

VAR nenner: RR; 

BEGIN 

nenner := cos(x); 

IE nenner =0.0 THEN 

ArithmeticError := TRUE; 

RETURN schrott; 

ELSE 

RETURN sin(x) / nenner 
END 

END UnserTan; 

PROCEDURE Sh(x: RR): RR; 

BEGIN 

RETURN (exp(x)-exp(-x)) / 2.0 
END Sh; 

PROCEDURE Ch(x: RR): RR; 

BEGIN 

RETURN (exp(x)+exp(-x)) / 2.0 
END Ch; 

PROCEDURE Th(x: RR): RR; 

BEGIN 

RETURN Sh(x) / Ch(x) 

END Th; 

PROCEDURE UnserLn(x: RR): RR; 

BEGIN 

IP x <= 0.0 THEN 

ArithmeticError := TRUE; 

RETURN schrott; 

ELSE 

RETURN ln (x) 

END 

END UnserLn; 

PROCEDURE UnserSqrt(x: RR): RR; 

BEGIN 

IP x < 0.0 THEN 

ArithmeticError := TRUE; 

RETURN schrott; 
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ELSE 

RETURN sqrt(x) 

END 

END UnserSqrt; 


PROCEDURE Sqr(x: RR): I 

BEGIN 

RETURN x*x 

END Sqr; 

IR; 

PROCEDURE Abs(x: RR): I 

BEGIN 

IP x < 0.0 

THEN RETURN -x 

ELSE RETURN x END 

END Abs; 

IR; 

PROCEDURE Sign(x: RR): 

RR; 


BEGIN 

IF x = 0.0 THEN RETURN 0.0 
ELSIP x > 0.0 THEN RETURN 1.0 
ELSE RETURN -1.0 END 
END Sign; 


PROCEDURE LehreKonstanten; 
BEGIN 


LerneVariable("PI”, 

, 3.14159265358979328); 

LerneVariable(”E”, 

exp (1.0)); 

LerneVariable(”A”, 

0.0); 

LerneVariable(”B”, 

0.0); 

LerneVariable(”C”, 

0 . 0) 

END LehreKonstanten; 


PROCEDURE LehrePunktionen; 

BEGIN 


LernePunkt ton^SIN’ 

% sin); 

LernePunktion(”COS’ 

% cos); 


LernePunktion(”TAN”, UnserTan); 
LernePunktion(”ARCTAN”, arctan); 
LernePunktion(”SINH”, Sh); 
LernePunktion(”COSH”, Ch); 

LernePunktion(”TANH”, Th); 
LernePunktion(”LN”, UnserLn); 
LernePunktion(”EXP”, exp); 
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LerneFunktion(”SQR”, Sqr); 
LerneFunktion(»SQRT», UnserSqrt); 
LerneFunktion(»ABS», Abs); 
LerneFunktion(»SIGN», Sign); 

END LehreFunktionen; 


PROCEDURE LehreRegeln; 

BEGIN 

LerneRegel(»TAN ARCTAN X», »X»); 
LerneRegel(»SIN X / COS X», »TAN X»); 
LerneRegel(»SQR SIN X + SQR COS X», ”1»); 
LerneRegel(»SIN 0”, ”0”); 

LerneRegel(»COS 0”, »1»); 

LerneRegel(»SIN PI”, »0»); 

LerneRegel(»COS PI», »-1»); 

LerneRegel(»SQR COSH X - SQR SINH X», »1»); 
LerneRegel(»EXP LN X», »X»); 

LerneRegel(»LN EXP X», »X»); 

LerneRegel(»E-'X», »EXP X»); 

LerneRegel(»SQRT SQR X», »ABS X”); 
LerneRegel(»SQR SQRT X», »X»); 

LerneRegel(»X*X», »SQR X”); 

»SQR X»); 

»X»); 

»X») 

»X») 


LerneRegel(»X~2», 
LerneRegel(»X~l», 
LerneRegel(”--X», 
LerneRegel(»0+X», 
LerneRegel(»X-0», »X») 
LerneRegel(»0-X», »-X» 
LerneRegel(»X-X», 
LerneRegel(”0*X», 
LerneRegel(»1*X», 
LerneRegel(»0/X», 
LerneRegel(»X/X», 
LerneRegel(»X/0», 

END LehreRegeln; 


); 


” 0 ») 

” 0 ”) 

»X») 

» 0 ») 

» 1 ») 

” 1/0 




PROCEDURE LehreAbleitungen; 

BEGIN 

LerneAbleitung(»SIN», »COS X»); 
LerneAbleitung(”COS», »-SIN X»); 
LerneAbleitung(»TAN»,»1/SQRC COS X»); 
LerneAbleitung(»ARCTAN», »1/(1+SQR X)»); 
LerneAbleitung(»SINH», »COSH X»); 
LerneAbleitung(»COSH», »SINH X»); 
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LerneAbleitung(”TANH”, »1/ SQR(COSH X)”); 
LerneAbleitung(»EXP», »EXP X»); 

LerneAbleitung(»LN», »1/X»); 
LerneAbleitung(»SQRT», »1/(2*SQRT X)»); 
LerneAbleitung(”SQR”, »2*X»); 
LerneAbleitung(»ABS», »SIGN X»); 
LerneAbleitung(»SIGN», »0»); 

END LehreAbleitungen; 

BEGIN 

LehreEunktionen; 

LehreKonstanten; 

LehreRegeln; 

LehreAbleitungen; 

END MatheLehrer. 


5.5 Optimiertes stabiles Integrationsverfahren 

Vielleicht kennen Sie aus der Schulmathematik die Keplersche Faßregel 
b 

(I) f f(x) dx = — (f(a) + 4 f(^±k) + f(b)) mit h = b - a 

J 6 2 
a 

Diese Regel ermittelt das gesuchte Integral aus den Funktionswerten am Intervallanfang, 
-mitte und -ende. Wenn man das Verfahren nicht auf das gesamte Intervall anwendet, sondern 
dieses zuvor in 8 Teile zerlegt und auf die Teilintervalle anwendet, ist es relativ genau. 

Nimmt man mehr Teilintervalle, ist das Ergebnis zwar exakter, die Rechenzeit wird aber 
höher. Das alte Lied! Wir greifen nun zu einem Trick: Wenn die Funktion nahezu konstant ist, 
reichen wenige Teilintervalle, um einen guten Wert für das Integral zu erhalten. Nur an den 
Stellen, wo sich der Funktionsgraph drastisch ändert, sind kleinere Teilintervalle angesagt. 
Man bringt also etwas Dynamik in die Sache! Die Vorteile der geringen Rechenzeit und des 
genauen Resultates werden kombiniert. 

Aber wie soll man wissen, wo sich der Funktionsgraph stark ändert? Hierzu berechnen wir das 
Integral auf einem Teilintervall nach einer zweiten, noch besseren Formel. Diese Formel ist 
ähnlich aufgebaut wie die erste, verwendet aber pro Teilintervall drei Stützstellen: 
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b 


(II) J f(x) dx =A( 7 f(a) + 32f( 


+ 12 f(^y) + 32 + 7 f(b)) 


a 


Wenn der Funktionsverlauf nun relativ glatt ist, werden sich die errechneten Werte nach For¬ 
mel (I) und nach Formel (II) kaum unterscheiden. Ansonsten halbieren wir das Intervall 
noch einmal, das ist alles! 

Man startet mit acht Teilintervallen. Bliebe noch zu sagen, daß die Berechnungen so angelegt 
sind, das kein Funktionsaufruf doppelt erfolgt. Das Verfahren ist also sehr effizient. 

DEFINITION MODULE Integrierer; 

TYPE Funktion = PROCEDURE(REAL) : REAL; 

PROCEDURE Integral( f : Funktion; 


(* Integrationsgrenzen *) 


a, b, 

Genauigkeit : REAL) : REAL; 


END Integrierer. 


IMPLEMENTATION MODULE Integrierer; 

PROCEDURE Integral( f: Funktion; a,b,Genauigkeit : REAL) : REAL; 

CONST 

minlntervalle = 8; 

VAR 

xO, xl, xm, fa, fb, fm, I, h : REAL; 
j : CARDINAL; 

PROCEDURE Teillntegral(a,m,b,fa,fm,fb : REAL); 

VAR II, I2,h,ml,m2, fml, fm2 : REAL; 

BEGIN 

h : = b - a; 
ml := (a + m)/2.0; 
fml : = f(ml); 
m2 := (m + b)/2.0; 
fm2 := f(m2); 

11 := (fa + 4.0*fm + fb) * h/6.0; (* Keplersche Faßregel *) 

12 := (7.0*(fa + fb) + 32.0*(fml + fm2) + 12.0*fm) * h/90.0; 


IF ABS(II - 12)Genauigkeit THEN 


(* noch bessere Regel *) 
(* wenn nicht in etwa gleich,... *) 
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Teillntegral(a,ml,m,fa,fml,fm); 
Teillntegral(m,m2,b,fm,fm2,fb) 

ELSE I : = I + 12 END 
END Teillntegral; 

BEGIN 

I : = 0.0; 

h : = (b - a)/ELOAT(minIntervalle); 
fb := f(a); xl : = a; 

FOR j : = 1 TO minlntervalle DO 
xO : = xl; fa : = fb; xl : = xO + h; 
fb:=f(xl); xm := (x0+xl)/2.0; fm:=f(xm); 
Teillntegral(xO,xm,xl,fa,fm,fb) 

END; 

RETURN I 
END Integral; 

END Integrierer. 


(* ... dann weiterteilen *) 
(* den besseren Wert aufsummieren *) 


5.6 Das komplette Programm »ModPlot« 

Die wichtigsten Teile des Programmpaketes sind besprochen. Es fehlt nur noch die Benutzer¬ 
schnittstelle: 

• Die Menüleiste 

• Diverse Dialogboxen zur Eingabe des Funktionsterms usw. 

• Alarmboxen 

• Die Grafikausgabe 

Die Methoden für diese Programmteile wurden im 4. Kapitel besprochen, weshalb es hier kei¬ 
ner weiteren Erläuterungen bedarf. Lassen Sie das Programm einfach laufen, es liegt auf der 
Diskette als Stand-alone-Version vor und kann also vom Desktop aus angeklickt werden. 
Schauen Sie sich den Programmablauf in allen Einzelheiten an. 

Wer noch Lust zum Forschen hat, für den sind die Benutzerschnittstellen-Module im folgen¬ 
den aufgelistet. Zunächst der Hauptmodul, er enthält im wesentlichen nur Menüauswertung 
und verteilt die Arbeit auf andere Schultern, ein echter Manager... 



Das komplette Programm »ModPlot« 


459 


MODULE ModPlot; 

IMPORT AESForms, AESGraphics, GEMEnv; 

FROM GEMGlobals IMPORT PtrObjTree; 

FROM AESMenus IMPORT MenuBar, NormalTitle, Checkitem; 

FROM AESEvents IMPORT MessageBuffer, MessageEvent, menuSelected; 

FROM AESResources IMPORT LoadResource, FreeResource, ResourceAddr, 

^ ResourcePart; 

IMPORT Grafik; 

IMPORT Dialoge, GraphPlot; 

IMPORT MatheLehrer; (* muss nur importiert werden! *) 

IMPORT Plotrsc; (* Die Resourcen-Definitionen für Menüs und Dialoge *) 


PROCEDÜRE BehandleMenue; 

VAR 

Menue : PtrObjTree; 

Nachricht: MessageBuffer; 

BEGIN 

Menue := ResourceAddr(treeRsrc, Mntree); 
MenuBar(Menue, TRÜE); 

LOOP 

GraphPlot. Erneuern; 

MessageEvent(Nachricht); (* 

CASE Nachricht. msgType OF 
menuSelected: 

CASE Nachricht.selltem OF 


Zeiger auf unser Menü *) 
(* Das Menue anzeigen *) 


warten auf Nachricht (Menü-Anwahl) *) 
(* Nachricht: Menüpunkt gewählt *) 


Mninfo : 

Dialoge. Info | 

Mnfun : 

Dialoge.FrageFunktion | 

Mnparms : 

Dialoge.FrageParameter j 

Mnwerte : 

GraphPlot.NeuerBereich i 

Mnhardcp: 

GraphPlot.Hardcopy i 

Mnneu : 

GraphPlot.GraphLoeschen | 

Mnplot : 

GraphPlot.PlotteFunktion j 

Mnintegr: 

Dialoge.Fragelntegral ( 

Mndiffer: 

GraphPlot.PlotteAbleitung 

Mnende 

EXIT 


ELSE 

(* 

END; 


END; 

NormalTitle(Menue, Nachricht.selTitle, TRUE) | 
andere Nachrichten berücksichtigen wir hier nicht 
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END 

END BehandleMenue; 

VAR Knopf: CARDINAL; (* Dummy *) 


BEGIN 

Grafik.anmelden; (* Anmelden bei AES und VDI *) 

AESGraphics.GrafMouse(AESGraphics. bee, NIL); (* Biene zeigen *) 

LoadResource("PLOTRSC.RSC”); (* Resource- File Laden *) 

AESGraphics.GrafMouse(AESGraphics. arrow, NIL); (* Pfeil zeigen *) 

IF GEMEnv.GemError() THEN (* Error: Alarmbox und abbruch *) 

AESForms.FormAlert(l,”[2][Das Resource~File| 

PLOTRSC.RSC|konnte nicht geladen werden!][Pech]”, 

Knopf) 

(*- nun kann es losgehen-*) 


ELSE 

GraphPlot.Init; 
BehandleMenue; 
GraphPlot.Ende 

END; 

Grafik.abmelden 
END ModPlot. 


(* Die Kommunikation mit dem Benutzer *) 
(* belegten Speicher freigeben *) 



Bild 5.9: Dialogbox für die Parametereingabe 
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Desk Eingeben 


Zeichnen 



- 2.000 - 1.500 


- 1 . -—-•---- •. 

■ - 1 * 0 - 0,0000000000001 
| Rechnen Fertig J: 


1.500 2.0 


-1 . 200 -- 


Bild 5.10: Dialogbox für das Integral 


Der Eingabemodul steuert die diversen Dialogboxen. Weil der Anwender und das Programm 
sich einiges zu erzählen haben, gibt es davon sechs: 

• Eingabe des Funktionsterms und der Parameter a,b und c 

• Eingabe der Parameter separat 

• Eingabe des Definitions- und Wertebereichs 

• Ausgabe des Terms der Ableitungsfunktion 

• Eingabe der Integrationsgrenzen und Integralausgabe 

• Ausgabe der Information über ModPlot (Programmlogo) 

Die Ausgabe des Strings der Ableitungsfunktion landet also in einer eigenen Box. Von hier aus 
hat man die Möglichkeit, diesen Funktionsterm als aktuellen in die Edierbox zu übernehmen, 
die Ableitung zu zeichnen oder die nächst höhere Ableitung zu ermitteln. Insgesamt erhält 
man vom Resource-Construktion-Set einen recht üppigen Datenmodul: 

DEFINITION MODULE Plotrsc; 

EXPORT Mntree, Mninfo, Mnfun, Mnparms, Mnwerte, Mnhardcp, 

Mnende, Mnneu, Mnplot, Mndiffer, Mnintegr, 

Dfun, Dfunfkt, Dfuna, Dfunb, Dfunc, Dfunok, Dfunabbr, 
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Dfunezgr, Dfunemsg, Dpar, Dpara, Dparb, Dparc, 

Dparok, Dparabbr, Dber, Dberxmin, Dberxmax, Dberymin, 
Dberymax, Dberok, Dberabbr, Dint, Dintvon, Dintbis, 
Dintrech, Dintende, Dinterg, Dintnako, Dinteps, Dinfo, 
Ddif, Ddifsl, Ddifs2, Ddifs3, Ddifs4, Ddifzahl, 
Ddifende, Ddifdif, Ddifplot; 


CONST 

Mntree 

= 

0; 

(* 

Menuebaum *) 


Mninfo 

= 

8; 

(* 

STRING in Baum MNTREE 

*) 

Mnfun 

= 

17; 

(* 

STRING in Baum MNTREE 

*) 

Mnparms 

= 

18; 

(* 

STRING in Baum MNTREE 

*) 

Mnwerte 

= 

19; 

(* 

STRING in Baum MNTREE 

*) 

Mnhardcp 

= 

21; 

(* 

STRING in Baum MNTREE 

*) 

Mnende 

= 

23; 

(* 

STRING in Baum MNTREE 

*) 

Mnneu 

= 

25; 

(* 

STRING in Baum MNTREE 

*) 

Mnplot 

= 

26; 

(* 

STRING in Baum MNTREE 

*) 

Mndiffer 

= 

28; 

(* 

STRING in Baum MNTREE 

*) 

Mnintegr 


29; 

(* 

STRING in Baum MNTREE 

*) 

Dfun 

= 

1; 

(* 

Formular/Dialog *) 


Dfunfkt 

= 

4; 

(* 

FBOXTEXT in Baum DFUN 

*) 

Dfuna 

= 

5; 

(* 

FBOXTEXT in Baum DFUN 

*) 

Dfunb 

= 

6; 

(* 

FBOXTEXT in Baum DFUN 

*) 

Dfunc 

= 

7; 

(* 

FBOXTEXT in Baum DFUN 

*) 

Dfunok 

= 

8; 

(* 

BUTTON in Baum DFUN *) 


Dfunabbr 

= 

9; 

(* 

BUTTON in Baum DFUN *) 


Dfunezgr 

= 

10; 

(* 

TEXT in Baum DFUN *) 


Dfunemsg 

= 

11; 

(* 

BOXTEXT in Baum DFUN * 

) 

Dpar 

= 

2; 

(* 

Formular/Dialog *) 


Dpara 

= 

1; 

(* 

FBOXTEXT in Baum DPAR 

*) 

Dparb 

= 

2; 

(* 

FBOXTEXT in Baum DPAR 

*) 

Dparc 

= 

3; 

(* 

FBOXTEXT in Baum DPAR 

*) 

Dparok 

= 

4; 

(* 

BUTTON in Baum DPAR *) 


Dparabbr 

= 

5; 

(* 

BUTTON in Baum DPAR *) 


Dber 

= 

3; 

(* 

Formular/Dialog *) 


Dberxmin 

= 

1; 

(* 

FBOXTEXT in Baum DBER 

*) 

Dberxmax 

= 

2; 

(* 

FBOXTEXT in Baum DBER 

*) 

Dberymin 

= 

3; 

(* 

FBOXTEXT in Baum DBER 

*) 

Dberymax 

= 

4; 

(* 

FBOXTEXT in Baum DBER 

*) 

Dberok 

= 

5; 

(* 

BUTTON in Baum DBER *) 


Dberabbr 


6; 

(* 

BUTTON in Baum DBER *) 


Dint 

= 

4; 

(* 

Formular/Dialog *) 


Dintvon 

= 

3; 

(* 

FTEXT in Baum DINT *) 


Dintbis 

= 

4; 

(* 

FTEXT in Baum DINT *) 
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Dintrech 

= 

5; 

(* 

BUTTON in Baum DINT *) 

Dintende 

= 

6; 

(* 

BUTTON in Baum DINT *) 

Dinterg 

= 

7; 

(* 

TEXT in Baum DINT *) 

Dintnako 

S 

9; 

(* 

FTEXT in Baum DINT *) 

Dinteps 

» 

11; 

(* 

FTEXT in Baum DINT *) 

Dinfo 

= 

5; 

(* 

Formular/Dialog *) 

Ddif 

= 

6; 

(* 

Formular/Dialog *) 

Ddifsl 

= 

2; 

(* 

TEXT in Baum DDIF *) 

Ddif s2 

= 

3; 

(* 

TEXT in Baum DDIF *) 

Ddifs3 

= 

4; 

(* 

TEXT in Baum DDIF *) 

Ddifs4 

= 

5; 

(* 

TEXT in Baum DDIF *) 

Ddifzahl 

= 

7; 

(* 

TEXT in Baum DDIF *) 

Ddifende 

= 

8; 

(* 

BUTTON in Baum DDIF *) 

Ddifdif 

= 

9; 

(* 

BUTTON in Baum DDIF *) 

Ddifplot 

= 

10; 

(* 

BUTTON in Baum DDIF *) 

END Plotrsc. 





Wie gewohnt ist der Implementationsmodul leer, wie es sich für einen Datenmodul gehört. 

IMPLEMENTATION MODULE Plotrsc; 

(*§>N+, M-*) 

END Plotrsc. 


Auf diesem Datenmodul baut nun die Verwaltung der verschiedenen Dialogboxen auf. Alles 
funktioniert nach dem im Abschnitt 4.8 besprochenen Rezepten. Die Länge kommt nur durch 
die Anzahl der Dialoge zustande. 

DEFINITION MODULE Dialoge; 

IMPORT GEMGlobals; 

IMPORT Parser; 

TYPE 

RR = Parser. RR; 

ParserBaum = Parser.ParserPtr; 

StrRR = ARRAY [0..15] OF CHAR; (* String für Reelle Zahlen *) 

StrFkt = ARRAY [0..60] OF CHAR; (* String für einen Funktionsterm *) 

ParmStrings = RECORD a,b,c: StrRR END; 

BerStrings = RECORD xMin, xMax, yMin, yMax: StrRR END; 
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VAR 


Parameter : RECORD 


dlog: 

StrS: 

GEMGlobals.PtrObjTree; 

ParmStrings; 

BezP: 

RECORD a,b,e: Parser.BezPtr END 

END; 


Punktion : RECORD 


dlog: 

Baum: 

GEMGlobals.PtrObjTree; (* Die Dialogbox *) 

ParserBaum; (* Der Punktionsbaum *) 

Stri: 

StrPkt; (* Der Punktionsstring *) 


ErrZeiger: StrFkt; 

ErrMeldung: ARRAY[0..30] OP CHAR; 
END; 


Bereich : RECORD 


dlog: 

StrS: 

GEMGlobals.PtrObjTree; 

BerStrings; 

xMin, 

xMax, yMin, yMax: RR 

END; 


Ableitung: RECORD 

dlog: 

Baum: 

GEMGlobals.PtrObjTree; 

ParserBaum; 

Zahl: 

CARDINAL; 

END; 


PROCEDURE Init; 

(* Werte vorbesetzen *) 

PROCEDURE Ende; 


PROCEDURE Info; 

(* Info- Box zeigen *) 


PROCEDURE PrageParameter; 
PROCEDURE PragePunktion; 

PROCEDURE FrageBereich: BOOLEAN; 
PROCEDURE Fragelntegral; 

PROCEDURE FrageAbleitung: BOOLEAN: 

END Dialoge. 

Hier der Implementationsmodul: 

IMPLEMENTATION MODULE Dialoge; 


PROM SYSTEM IMPORT ADR; 

IMPORT GEMGlobals, GrafBase, ObjHandler; 
IMPORT AESObjects, AESPorras; 
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PROM AESResources IMPORT ResourceAddr, ResourcePart; 

IMPORT Strings, StrConv, ZKetten; 

IMPORT Parser, Integrierer, Differenzierer; 

PROM Optiraierer IMPORT BaumCopy, Optimiere; 

IMPORT Plotrsc; 

VAR 

DlgBox: RECORD (* Dialogboxen für Integral und die Info-Box *) 

Integral, Info: GEMGlobals.PtrObjTree; 

END; 

MODULE DialogVerwalter; 

PROM AESPorms IMPORT PormCenter, PormDial, FormDialMode, FormDo; 

PROM AESObjects IMPORT DrawObject; 

FROM GEMGlobals IMPORT PtrObjTree, OStateSet, Root, MaxDepth; 

FROM GrafBase IMPORT Rectangle, Reet; 

FROM ObjHandler IMPORT SetObjState, SetCurrObjTree, 

GetTextStrings, AssignTextStrings, SetPtrChoice; 

EXPORT Dialoglnit, DialogFuehren, DialogEnde, TexLesen, TexSchreiben; 

VAR BoxKlein, BoxGross: Rectangle; 


PROCEDURE Dialoglnit(dlog: PtrObjTree); 

BEGIN 

BoxKlein := Reet(300,200,50,30); (* ein kleines Rechteck in der Mitte *) 


BoxGross := FormCenter(dlog); 
FormDial(reserveForm, BoxKlein, BoxGross); 
FormDial(growPorm, BoxKlein, BoxGross); 
SetCurrObjTree(dlog, FALSE); 

END Dialoglnit; 


(* Größe der Dialogbox *) 
(* Bildschirm reservieren *) 
(* ZOOM klein -> groß *) 


PROCEDURE DialogEnde(dlog: PtrObjTree); 

BEGIN 

PormDial(shrinkForm, BoxKlein, BoxGross); 
FormDial(freeForm, BoxKlein, BoxGross) 

END DialogEnde; 


(* ZOOM groß - --> klein *) 
(* Bildschirm freigeben *) 


PROCEDURE DialogFuehren(dlog: PtrObjTree; VAR EndeKnopf: CARDINAL); 

BEGIN 

DrawObject(dlog, Root, MaxDepth, BoxGross); (* Dialog-Box zeichnen *) 

FormDo (dlog, Root, EndeKnopf); (* Benutzereingaben *) 
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SetObjState(EndeKnopf, OStateSet{}); (* Ende-Knopf wieder normal *) 

END DialogEuehren; 

(* Einen String aus der Dialogbox lesen -- *) 

PROCEDURE TexLesen(Objekt: CARDINAL; VAR str: ARRAY OE CHAR); 

VAR duramy : ARRAY[0,.80] OE CHAR; 

BEGIN 

GetTextStrings(Objekt, str, dummy, dummy); 

END TexLesen; 

(* Einen String in die Dialogbox schreiben -- *) 

PROCEDURE TexSchreiben(Objekt: CARDINAL; str: ARRAY OP CHAR); 

BEGIN 

AssignTextStrings(Objekt, setOnly, str, noChange, ’’,noChange,’’); 

END TexSchreiben; 

END DialogVerwalter; 

(* Eine reelle Zahl aus der Dialogbox lesen--— 

PROCEDURE Ree11eLesen(Objekt: CARDINAL; VAR ok: BOOLEAN) 

VAR str: StrRR; 

wert: RR; 

BEGIN 

TexLesen(Objekt, str); 
wert := ZKetten.reell(str, ok); 

IE NOT ok THEN TexSchreiben(Objekt, ”<???>”) END; 

RETURN wert 
END ReelleLesen; 

PROCEDURE Info; (* <- Anzeigen der Informations-Box *) 

VAR Knopf: CARDINAL; 

BEGIN 

Dialoglnit(DlgBox. Info); 

DialogEuehren(DlgBox.Info, Knopf); 

DialogEnde(DlgBox. Info) 

END Info; 

PROCEDURE LeseParameter: BOOLEAN; (* --— holt Parameter aus der Dialogbox *) 
VAR okl,ok2,ok3: BOOLEAN; 

BEGIN 

WITH Parameter DO 

Parser.SetzeVariable(BezP. a, ZKetten. reell(StrS. a, okl)); 

Parser. SetzeVariable(BezP.b, ZKetten. reell(StrS. b, ok2)); 

Parser.SetzeVariable(BezP.c, ZKetten.reell(StrS. c, ok3)) END; 


- *) 

: RR; 
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RETURN okl AND ok2 AND ok3 
END LeseParameter; 

PROCEDURE PrageParameter; (* <- neue Parameter über Dialogbox holen *) 

VAR 

EndeKnopf: CARDINAL; 

AlteParms: ParmStrings; 

BEGIN 

AlteParms := Parameter. StrS; 

Dialoglnit(Parameter.dlog); (* Speicher reservieren und Effekte *) 

REPEAT 

DialogPuehren(Parameter. dlog, EndeKnopf); (* Benutzereingaben *) 

IE EndeKnopf = Dparabbr THEN Parameter. StrS : = AlteParms END; 

UNTIL LeseParameter() OR (EndeKnopf = Dparabbr); 

DialogEnde(Parameter, dlog); 

END PrageParameter; 

PROCEDURE Melde(s: ARRAY OP CHAR); 

VAR i : CARDINAL; 

BEGIN 

TexSchreiben(Dfunemsg, s); 

END Melde; 

PROCEDURE ZeigeFehler; (* Fehler und Position anzeigen *) 

VAR i: CARDINAL; 

BEGIN 

POR i : = 0 TO Parser.ScanErrPos DO Punktion. ErrZeiger[i] := 

END; 

Punktion.ErrZeiger[Parser.ScanErrPos] := 

Punktion.ErrZeiger[Parser.ScanErrPos+1] := OC; 

TexSchreiben(Dfunezgr, Punktion.ErrZeiger); 

CASE Parser.ErrorArt OP 

Parser.errCharacter : Melde("unerlaubtes Zeichen”) j 
Parser. errBezeichner : Melde("unbekannter Bezeichner”) | 

Parser.errKlamraerZu : Melde(’”)” erwartet’) | 

Parser. errAusdruck : Melde("Ausdruck erwartet”) | 

Parser.errOperator : Melde(”Operator erwartet”) 

ELSE Melde("Syntax-Fehler”) 

END 

END ZeigeFehler; 

PROCEDURE PragePunktion; (* <- Punktion eingeben lassen *) 

VAR 

AlteFkt: Parser.ParserPtr; 
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AlteStr: StrFkt; 

AlteParms: ParmStrings; 

EndeKnopf: CARDINAL; 

BEGIN 

AltePkt := Punktion.Baum; (* Alte Werte merken (für Abbruch) *) 

AlteStr := Punktion.Stri; 

AlteParms := Parameter. StrS; 

DialogInit(Punktion. dlog); 

Melde(”<Punktion und Parameter angeben>”); 

TexSchreiben(Dfunezgr, ””); 

LOOP 

DialogPuehren(Punktion.dlog, EndeKnopf); 

IP EndeKnopf = Dfunabbr THEN (* Abbruch gedrückt? *) 


Punktion. Baum := AltePkt; (* alte Werte wiederherstellen *) 

Punktion.Stri := AlteStr; 

Parameter.StrS := AlteParms; 

EXIT (* -> Abbruch = = > Fertig *) 

ELSE 


IF LeseParameter() THEN (* Parameter ok? *) 

IP ZKetten.gleich(AlteStr, Punktion. Stri) THEN (* neue Punktion? *) 


EXIT (* -> Parameter ok = = > Fertig *) 

ELSE (* neue Punktion eingegeben ==> parsen *) 


Punktion.Baum := Parser.parse(Punktion. Stri); 

IP NOT Parser.SyntaxError THEN (* Punktion ok? *) 

Parser.LoescheBaum(AltePkt); (* Alte Punktion löschen *) 

Parser.LoescheBaum(Ableitung. Baum); (* Ableitung ungültig *) 

EXIT (* -> Parms & Punktion ok = = > Fertig *) 

ELSE ZeigePehler (* Fehler in der Dialogbox anzeigen *) 

END 

END 

ELSE 

Melde("Parameter A,B oder C ungültig!”) (* in der Box anzeigen *) 

END 

END 

END; 

DialogEnde(Punktion.dlog) (* Dialogbox abmelden *) 

END PragePunktion; 

PROCEDURE LeseBereich: BOOLEAN; (* Bereich für X/Y aus der Box lesen *) 

VAR 

s: StrRR; 

okl, ok2, ok3, ok4: BOOLEAN; 

BEGIN 


WITH Bereich DO 
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xMin := ReelleLesen(Dberxmin, okl); 
xMax : = ReelleLesen(Dberxmax, ok2); 
yMin := ReelleLesen(Dberymin, ok3); 
yMax : = ReelleLesen(Dberymax, ok4); 

RETURN okl AND ok2 AND ok3 AND ok4 AND (xMin<xMax) AND (yMin<yMax) 
END 

END LeseBereich; 


PROCEDURE ErageBereich: BOOLEAN; (* neuen Bereich eingeben lassen *) 

VAR 

EndeKnopf: CARDINAL; 

SxMin, SxMax, SyMin, SyMax: StrRR; (* Strings für reelle Zahlen *) 

BEGIN 

Dialoglnit(Bereich.dlog); 

TexLesen(Dberxmin, SxMin); (* Alte Werte merken, da sie bei ... *) 

TexLesen(Dberxmax, SxMax); (* Abbruch restauriert werden müssen *) 

TexLesen(Dberymin, SyMin); 

TexLesen(Dberymax, SyMax); 

REPEAT 

DialogEuehren(Bereich.dlog, EndeKnopf); 

IP EndeKnopf = Dberabbr THEN (* Abbruch => Werte Restaurieren *) 

TexSchreiben(Dberxmin, SxMin); 

TexSchreiben(Dberxmax, SxMax); 

TexSchreiben(Dberymin, SyMin); 

TexSchreiben(Dberymax, SyMax) 

END 

UNTIL LeseBereich() OR (EndeKnopf = Dberabbr); 

DialogEnde(Bereich.dlog); 

RETURN EndeKnopf = Dberok 
END ErageBereich; 


PROCEDURE f(x: RR):RR; 

BEGIN 

RETURN Parser.berechne(Punktion.Baum, x) 
END f; 


PROCEDURE PrägeIntegral; 
VAR 


o 


Integral-Dialog führen *) 


dlog 

EndeKnopf 

epsilon 

nako 

von,bis, igr 
okl,ok2,ok3 


GEMGlobals.PtrObjTree; 

CARDINAL; 

RR; 

CARDINAL; (* Zahl der gewünschten Nachkommastellen *) 

RR; 

BOOLEAN; 





470 


Das komplette Programm »ModPlot« 


str : StrRR; 

BEGIN 

Dialoglnit(DlgBox.Integral); 

TexSchreiben(Dinterg,”<!>”); 

LOOP 

DialogEuehren(DlgBox. Integral, EndeKnopf); 

IE EndeKnopf = Dintende THEN EXIT END; 
von := ReelleLesen(Dintvon, okl); (■* 

bis := ReelleLesen(Dintbis, ok2); ( 

epsilon : = ReelleLesen(Dinteps, ok3); 

TexLesen(Dintnako, str); 
nako := ZKetten. card(str); 

IF okl AND ok2 AND ok3 THEN 

igr := Integrierer.Integral(f, von, bis, epsilon); 
ZKetten.RzuS(igr, nako, str); 

TexSchreiben(Dinterg, str) 

ELSE 

TexSchreiben(Dinterg,”...?”) 

END 

END; 

DialogEnde(DlgBox.Integral) 

END Pragelntegral; 


untere Integrationsgrenze *) 
obere Integrationsgrenze *) 
(* Genauigkeit *) 
(* Nachkommastellen *) 


(* Eunktionsterm in die Dialogbox schreiben *) 


PROCEDURE EunktionSchreiben; 

VAR s: StrEkt; ok: BOOLEAN; 

ss: ARRAY[0..4*60] OE CHAR; 

BEGIN 

Parser.BaumZuString(Ableitung.Baum, ss); 

Strings.Copy(ss, 0*60, 60, s, ok); TexSchreiben(Ddifsl, s); 


Strings.Copy(ss, 1*60, 60, 
Strings.Copy(ss, 2*60, 60 
Strings.Copy(ss, 3*60, 60 
END Funktionschreiben; 


60, 

s, 

ok); 

60, 

s, 

ok); 

60, 

s, 

ok); 

60, 

s, 

ok); 


ok); TexSchreiben(Ddifs2, s); 
ok); TexSchreiben(Ddifs3, s); 
ok); TexSchreiben(Ddifs4, s); 


PROCEDURE ErageAbleitung: BOOLEAN; 

VAR 

NeueAbleitung: ParserBaum; 

Zahlstr: ARRAY[0..5] OE CHAR; 

EndeKnopf: CARDINAL; 

BEGIN 

Dialoglnit(Ableitung, dlog); 

IF Ableitung.Baum = NIL THEN (* Wenn noch nicht abgeleitet wurde... 

Ableitung.Baum := BaumCopy(Funktion. Baum); (* Funktion übernehmen 

Optimiere(Ableitung.Baum); 


*) 
*) 
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Ableitung.Zahl := 0 END; 

LOOP 

PunktionSchreiben; | (* Funktionsterra in die Dialogbox bringen *) 

ZKetten.CzuS(Ableitung.Zahl, ZahlStr); | (* Nummer der Ableitung *) 

TexSchreiben(Ddifzahl, ZahlStr); 

DialogFuehren(Ableitung.dlog, EndeKnopf); 

CASE EndeKnopf OP 

Ddifende, Ddifplot: EXIT | (* fertig oder plotten -> raus *) 

Ddifdif: | (* einmal ableiten, bitte *) 

NeueAbleitung := Differenzierer. Ableitung(Ableitung. Baum); 

Parser.LoescheBaum(Ableitung. Baum); j (* Alten Baum löschen *) 

Ableitung.Baum := NeueAbleitung; 

INC(Ableitung.Zahl) | (* die wievielte haben wir den nun? *) 

END; 

END; 

DialogEnde(Ableitung, dlog); 

RETURN EndeKnopf = Ddifplot 
END FrageAbleitung; 


PROCEDURE Init; | (* <- Alle Initialisierungen und Vorbesetzungen *) 

BEGIN 

Parameter.dlog := ResourceAddr(treeRsrc, Dpar); 

Punktion.dlog := ResourceAddr(treeRsrc, Dfun); 

Bereich.dlog := ResourceAddr(treeRsrc, über); 

Ableitung.dlog := ResourceAddr(treeRsrc, Ddif); 

DlgBox.Integral := ResourceAddr(treeRsrc, Dint); 

DlgBox.Info := ResourceAddr(treeRsrc, Dinfo); 


ObjHandler.SetCurrObjTree(Parameter.dlog, PALSE); 
ObjHandler.LinkTextString(Dpara, ADR(Parameter. StrS. a)); 
ObjHandler. LinkTextString(Dparb, ADR(Parameter.StrS.b)); 
ObjHandler. LinkTextString(Dparc, ADR(Parameter. StrS.c)); 
ObjHandler.SetCurrObjTree(Punktion.dlog, PALSE); 
ObjHandler.LinkTextString(Dfuna, ADR(Parameter. StrS.a)); 
ObjHandler. LinkTextString(Dfunb, ADR(Parameter. StrS.b)); 
ObjHandler.LinkTextString(Dfunc, ADR(Parameter. StrS. c)); 
ObjHandler. LinkTextString(Dfunfkt, ADR(Funktion.Stri)); 
Parameter.StrS. a := ”0”; 

Parameter.StrS. b : = ”0”; 

Parameter. StrS. c : = ”0”; 

Punktion. Stri := ”X”; 

ObjHandler. SetCurrObjTree(Bereich.dlog, PALSE); 
TexSchreiben(Dberxmin, ”-5”); 

TexSchreiben(Dberxmax, ”5”); 

TexSchreiben(Dberymin, ”-3”); 
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TexSchreiben(Dberymax, ”3”); 

IF NOT LeseBereich() THEN HALT END; (* initialer Bereich ungültig *) 

ObJHandler.SetCurrObjTree(DlgBox.Integral, EALSE); 

TexSchreiben(Dintvon, ”0”); (* Integralgrenzen *) 

TexSchreiben(Dintbis, ”1”); 

Parameter. BezP.a := Parser.HoleBezeichner(”A”); 

Parameter.BezP.b := Parser.HoleBezeichner(”B”); 

Parameter.BezP.c := Parser.HoleBezeichner(”C”); 

IP NOT LeseParameter() THEN HALT END; (* initiale Parameter falsch *) 

Punktion. Baum := Parser.parse(Punktion. Stri); 

IP Parser.SyntaxError THEN HALT END; (* initiale Punktion fehlerhaft *) 

Ableitung. Baum :"= NIL; (* gibt noch keine *) 

END Init; 

PROCEDURE Ende; 

BEGIN 

Parser.LoescheBaum(Funktion.Baum); (* Speicher freigeben *) 

Parser. LoescheBaum(Ableitung.Baum); 

END Ende; 

END Dialoge. 


Zu guter Letzt der Modul zur Grafikausgabe. Hier muß man sich etwas mit den Polstellen der 
Funktionen herumärgern. Im großen und ganzen kann die Arbeit aber auf unseren Modul 
GrafikWelt abgewältzt werden. Insbesondere AchsenKreuz leistet wieder gute Dienste. 
Etwas lästig ist auch noch das Neuzeichnen der Grafik nach dem Abgang einer Dialogbox 
vom Bildfläche. Hierzu wird der Bildschirminhalt zwischengepuffert und anschließend 
schnell zurückgeschrieben. Dies erledigt ein separater Modul Bildschirm, der unten ausge¬ 
druckt wird. Zunächst die Grafikroutinen: 

DEFINITION MODULE GraphPlot; 

IMPORT Parser; 

TYPE 

RR = Parser.RR; 

ParserBaum = Parser.ParserPtr; 

PROCEDURE Init; 

PROCEDURE Ende; 

PROCEDURE Sichern; 

PROCEDURE Erneuern; 


(* muß immer zuerst aufgerufen werden *) 

(* Bildschirm sichern fürs Restaurieren *) 
(* Bildschirm restaurieren *) 
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PROCEDURE Hardcopy; 

PROCEDURE GraphLoeschen; (* Bildschirm löschen und Achsenkreuz zeichnen *) 

PROCEDURE NeuerBereich; 

PROCEDURE PlottePunktion; 

PROCEDURE PlotteAbleitung; 

END GraphPlot. 

Der Implementationsmodul folgt sogleich: 

IMPLEMENTATION MODULE GraphPlot; 

IMPORT Grafik,GrafikWelt, Bildschirm, XBIOS; 

IMPORT Parser; 

PROM VDIInputs IMPORT ShowCursor, HideCursor; 

PROM Dialoge IMPORT Funktion, Parameter, Bereich, Ableitung; 

IMPORT Dialoge; 

CONST 

PixXl = 10; PixX2 = 630; 

PixYl = 20; PixY2 = 392; 

PROCEDURE Sichern; 

BEGIN 

HideCursor(Grafik.Geraet); 

Bildschirm. ZeilenRetten(PixYl, PixY2); 

ShowCursor(Grafik.Geraet, FALSE) 

END Sichern; 

PROCEDURE Erneuern; («Brutaler, aber wirkungsvoller Redraw*) 

BEGIN 

HideCursor(Grafik.Geraet); 

Bildschirm.ZeilenErneuern(PixYl, PixY2); 

ShowCursor(Grafik.Geraet, FALSE) 

END Erneuern; 

PROCEDURE Hardcopy; 

BEGIN 

HideCursor(Grafik.Geraet); 

Erneuern; 

XBIOS.ScreenDump; 

ShowCursor(Grafik.Geraet, FALSE); 

END Hardcopy; 


(* Maus unsichtbar *) 
(* Bildschirm sichern *) 
(* Maus wieder sichtbar *) 
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PROCEDURE GraphLoeschen; 

BEGIN 

WITH Bereich DO 

Grafik.Hintergrund; 

GrafikWelt.SetzeSkalierung(xMin, yMin, xMax, yMax); 

GrafikWelt. AchsenKreuz((xMax-xMin)/10.0, (yMax-yMin)/10.0, 3,3, ”X”, ”Y”); 
Sichern; 

END 

END GraphLoeschen; 

PROCEDURE NeuerBereich; 

BEGIN 

IE Dialoge.FrageBereich() THEN GraphLoeschen END 
END NeuerBereich; 

PROCEDURE Move(x,y: RR); 

BEGIN 

Grafik.Move(GrafikWelt.KonvertX(x), GrafikWelt. KonvertY(y)); 

END Move; 

PROCEDURE Draw(x,y:RR); 

BEGIN 

Grafik. Draw(GrafikWelt.KonvertX(x), GrafikWelt.KonvertY(y)); 

END Draw; 

PROCEDURE Plotten(Ekt: ParserBaum); 

CONST 

Toleranz = 5.0; 

Schritte = 200.0; 

VAR 

x,y, DeltaX : RR; 

MinTol, MaxTol : RR; 
innen : BOOLEAN; 

BEGIN 

HideCursor(Grafik.Geraet); (* Maus immer vor dem Malen verstecken *) 

Erneuern; (* Bildschirm muß sauber sein *) 

DeltaX : = (Bereich.xMax-Bereich.xMin) / Schritte; 

MaxTol := Bereich.yMax + Toleranz * (Bereich. yMax-Bereich.yMin); 

MinTol := Bereich. yMin - Toleranz * (Bereich. yMax-Bereich.yMin); 
x := Bereich.xMin; 
innen := FALSE; 

WHILE x <= Bereich.xMax DO 

y := Parser.berechne(Fkt, x); (* einen Funktionswert berechnen *) 

IF Parser.ArithmeticError THEN innen := FALSE 
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ELSIF y < MinTol THEN innen := FALSE 

ELSIF y > MaxTol THEN innen := FALSE 

ELSE 

IF innen THEN Draw(x,y) ELSE Move(x,y) END; 
innen := TRUE 

END; 

x := x + DeltaX; 

END; 

Sichern; 

ShowCursor(Grafik.Geraet, FALSE); (* Maus wieder sichtbar *) 

END Plotten; 

PROCEDURE PlotteFunktion; 

BEGIN 

Plotten(Funktion.Baum) 

END PlotteFunktion; 

PROCEDURE PlotteAbleitung; 

BEGIN 

IF Dialoge. FrageAbleitung() THEN Plotten(Ableitung.Baum) END; 

END PlotteAbleitung; 

PROCEDURE Init; 

BEGIN 

Dialoge.Init; 

Grafik. SetzeBereich(PixXl,PixYl, PixX2,PixY2); 

GraphLoeschen; 

END Init; 

PROCEDURE Ende; BEGIN Dialoge.Ende END Ende; 

END GraphPlot. 

Nun noch der oben angesprochene Modul zur Pufferung und Rekonstruktion des Bild¬ 
schirms: 

DEFINITION MODULE Bildschirm; 

CONST 

BytesProZeile = 80; 

(* - - 

* Mit diesen Routinen läßt sich der Bildschirm wieder restaurieren, 

* nachdem er (z.B. durch eine Dialogbox) zerstört worden ist, wenn 
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* man sich nicht großartig mit ”Window-Redraw’s” abgeben will. 

* Hier wird einfach der Bildschirmspeicher kopiert; das ist zwar 

* brutal, aber recht effektiv zu benutzen. 

/ . 

*) 

PROCEDURE ZeilenRetten(yMin, yMax: CARDINAL); 

(* Rettet die Bildschirmzeilen yMin bis yMax 

* in einen gesonderten Speicherbereich 
*) 

PROCEDURE ZeilenErneuern(yMin, yMax: CARDINAL); 

(* 

* restauriert die mit *ZeilenRetten’ gesichterten Zeilen 
*) 

END Bildschirm. 


IMPLEMENTATION MODULE Bildschirm; 

PROM SYSTEM IMPORT BYTE, ADR, ADDRESS; 

PROM LowLevel IMPORT CopyN; 

IMPORT XBIOS; 

TYPE 

Bild = ARRAY [0..31999] OF BYTE; (* soll den Bildschirm aufnehmen *) 

VAR 

BildschirmPtr : POINTER TO Bild; 

SchirraKopie: Bild; 

PROCEDURE ZeilenRetten(yMin, yMax: CARDINAL); 

VAR i: CARDINAL; 

BEGIN 

CopyN(ADDRESS(BildschirmPtr) + LONG(yMin*BytesProZeile), 
ADR(SchirmKopie) + LONG(yMin*BytesProZeile), 

(yMax-yMin+1) * BytesProZeile) 

(* Entspricht in etwa: -> 

POR i : = yMin*BytesProZeile TO yMax*BytesProZeile DO 
SchirmKopie[i] := BildschirmPtr“[i] 

END 

< - - *) 


END ZeilenRetten; 
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PROCEDURE ZeilenErneuern(yMin, yMax: CARDINAL); 

VAR i: CARDINAL; 

BEGIN 

CopyN(ADR(SchirmKopie) + LONG(yMin*BytesProZeile), 

ADDRESS(BildschirmPtr) + LONG(yMin*BytesProZeile), 
(yMax-yMin+1) * BytesProZeile) 

(* Entspricht in etwa: -> 

EOR i := yMin*BytesProZeile TO yMax*BytesProZeile DO 
BildschirmPtr''[i ] := SchirmKopie[i] 

END 

<------*) 

END ZeilenErneuern; 

BEGIN 

BildschirmPtr := XBIOS.ScreenPhysicalBase(); 

END Bildschirm. 

Damit sind alle Teile des Projekts ModPlot besprochen. 
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Ausblick 


In diesem Buch haben wir uns das Ziel gesetzt, eine vollständige Einführung in Modula-2 zu 
geben, und Sie von der Schönheit und Stärke dieser Sprache - insbesondere der modularen 
Programmierung-zu überzeugen. Wir hoffen, daß Sie in den Bibliotheksmodulen Brauchba¬ 
res für Ihre Programmierpraxis und in den zahlreichen Programmbeispielen Anregendes zur 
Weiterarbeit gefunden haben. 

Zum Abschluß möchten wir noch einmal auf das Vorwort zurückkommen. Hier wurde be¬ 
richtet, daß Modula-2 etwa seit zehn Jahren existiert. In der Zwischenzeit ist die Forschung an 
der ETH Zürich nicht stehengeblieben. Die mehrjährige Programmiererfahrung mit Modula 
haben N. Wirth und sein Team veranlaßt, Ende 1987 eine Weiterentwicklung namens 
»Oberon« zu veröffentlichen. 

Oberon geht aus Modula mit einigen Erweiterungen und etlichen Streichungen hervor. Es 
handelt sich also insofern nicht um eine wesentlich neue Sprache, sondern sie bildet vielmehr 
das zunächst letzte Glied der Kette Algol, Pascal, Modula. 

Neu an Oberon ist die Möglichkeit, Datentypen als Erweiterung bereits vorhandener zu defi¬ 
nieren. Ein Beispiel: 

TYPE T = RECORD x,y : INTEGER END; 

Hiermit läßt sich als Typerweiterung definieren: 

TYPE TI = RECORD(T) z : REAL END; 

Der Typ T1 enthält nun dieselben Komponenten wie T und zusätzlich noch z. T heißt Basistyp 
zu T1, T1 ist die Erweiterung zu T. Gemeinsame Komponenten des erweiterten Typs sind zu¬ 
weisungskompatibel zu entsprechenden Variablen des Basistyps. Durch dieses Sprachkon- 
strukt ist es in Oberon möglich, nicht nur wie in Modula durch Prozeduren den Sprachkern zu 
erweitern, sondern auch durch Datentypen. Insbesondere für den Umgang mit Zeigervaria¬ 
blen eröffnet dies neue Möglichkeiten. Neben der Typerweiterung gibt es auch die Typinklu¬ 
sion. Oberon hat die fünf numerischen Datentypen 

LONGINT, INTEGER, SHORINT (ganzahlige Typen) 

LONGREAL, REAL (reelle Typen) 

Hier ist folgende Inklusionsbeziehung gegeben: 

LONGREAL 0 REAL 3 LONGINT 3 INTEGER 3 SHORTINT 

T 3 T’ besagt dabei, daß eine Variable vom T’ einer Variablen vom Typ T zugewiesen werden 
kann. Ist beispielsweise i vom Typ INTEGER, k vom Typ LONGINT und x vom Typ REAL, 
so sind die folgenden Zuweisungen zulässig: 
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k:=i; x:=k; k:=k + i; x:=x*10 + i; 

Nicht akzeptiert hingegen würde i : = k oder k : = x. 

Gegenüber Modula wurden etliche Konstrukte weggelassen. Teilweise steht dies im Zusam¬ 
menhang mit den genannten Erweiterungen, teilweise geschah es, um den Compiler zu entlas¬ 
ten und das System möglichst klein zu halten. Es gibt in Oberon keine Varianten Verbünde und 
keine opaken Typen. Das Geheimnisprinzip kann jetzt dadurch gewahrt werden, daß im De- 
finitionsteil nicht sämtliche Komponenten eines Verbundtypes deklariert werden müssen. 
Aufzählungstypen, Unterbereichstypen und der Datentyp CARDINAL fallen fort. Der klein¬ 
ste Index eines Feldes ist stets Null. Zeiger können nur auf Verbünde oder Felder zeigen. Der 
Modul SYSTEM entfallt und mit ihm die Datentypen ADDRESS und WORD. Der Import von 
Bezeichner aus anderen Modulen darf nur noch qualifiziert geschehen. Es gibt keine lokalen 
Module mehr, keine FOR-Schleife, kein Coroutinenkonzept als Sprachbestandteil (mögli¬ 
cherweise aber als externen Modul) und die WITH-Anweisung hat eine geänderte Bedeutung. 

Ansonsten bleibt aber alles beim Alten, so stimmen die Schlüsselwörter, die Standardfunktio¬ 
nen und die Syntaxregeln im großen und ganzen mit denen von Modula überein. 

Sicherlich bieten nicht alle beschriebenen Streichungen Anlaß zu spontanem Jubel. Man wird 
sehen, ob die neuen Konzepte genügend Tragfähigkeit besitzen, derart viele Sprachkon- 
strukte adäquat zu ersetzen. 

Bis die Sprache Oberon auch für unsere Rechnerkategorie kommt - wenn sie denn überhaupt 
kommt - wird sicher noch geraume Zeit vergehen. Eine Anfrage bei Professor Wirth Ende 
1988 ergab, daß noch keine Implementierungen für Kleinrechner bekannt sind. Vielleicht 
dauert es wieder noch ein Jahrzehnt bis zu einer größeren Verbreitung. Bis dahin haben Sie mit 
Modula-2 eine leistungsstarke und elegante Sprache, die gemeinsam mit der guten Maschine 
Atari ST ein machtvolles Werkzeug für die Erstellung Ihrer Programmprojekte bietet! 
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B. Syntaxdiagramme 

Alle Syntax-Diagramme sind in diesem Anhang noch einmal zusammengefaßt; sie sollen bei 
der Klärung von Fragen nach der Schreibweise bestimmter Programmkonstruktionen helfen. 
Die Syntaxdiagramme sind mit Nummern versehen. Die folgende alphabetische Aufstellung 
soll das Auffinden eines gesuchten Diagrammes erleichtern. 


ArrayType 19 

Number 3 

Assignment 46 

OctChario 

Blockj 2 

OctInteger 6 

CaseLabelList 2 4 

ParamSection 5 8 

CaseStatement 48 

PointerType 25 

ConstDeclaration 26 

Priority 7 2 

ConstElement 34 

ProcedureCall 60 

ConstExpr 27 

ProcedureDeclaratiom 

ConstFactor 32 

ProcedureHeading 56 

ConstSet 33 

ProcedureType 62 

ConstTerm 30 

ProgramModuleü 

Declnteger 5 

Qualldent 2 

Declaration i3 

Real 8 

Definition 68 

RecordType 20 

DefinitionModule 67 

Relation 28 

Designator 38 

RepeatStatement 5 o 

Element 44 

ReturnStatement 6 i 

Enumeration! 5 

Set 43 

ExitStatement 53 

Setfypei 7 

Export 66 

SimpleConstExpr 2 9 

Expression 39 

SimpleExpression 40 

Factor 42 

SimpleType 18 

FieldList 21 

Statement 45 

FormalParameters 57 

Statement Sequence j 4 

FormalType 5 9 

String 9 

FormalTypeList 63 

Subrange i 6 

ForStatement 51 

Term 4 i 

Hexlnteger 7 

Type 36 

Ident! 

TypeDeclaration 35 

IfStatement 47 

TypeDefmition 6 9 

ImplementationModule 70 

TypeTransfer 71 

Import 65 

VariableDeclaration 37 

Integer 4 

Variant 23 

LoopStatement 52 

VariantFieldList 22 

ModuleDeclaration 64 

WhileStatement 4 9 

MulOperator 31 

WithStatement 54 
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Idente 


Qualldent2 


Numbe^ 


Integer^ 



Declnteger 5 


/-^ 

i- ^digit^ —^ 




































Anhang 


489 


OctInteger 6 



Hexlnteger 7 
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OctChar 10 


\ \ \ \ \ \ \ \ 

(°) (p (p (p (p (p (p (p 


•©-* 


ProgramModule^ 






r 

Import 65 

(module)—► 

Ident t 


Priority 7 2 



A * 





V_ 


/ 



q 


Block 


12 — END) —► Ident i ——► 


Block 12 


Declaration 13 


^BEGIN^—► StatementSequence 14 


Declaration^ 


CONST 




ConstDeclaration 2 e 


n 


TYPE ~)-£— 


TypeDeclaration 35 


n 


< var > 


n 


VariableDeclaration 37 




ProcedureDeclaration 55 


ModuleDeclaration M 
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StatementSequence 14 


[ — 

Statement 45 


Enumeration 15 



Subrange 16 


Quaiident 


ConstExpr 27 ConstExpr 2 7 ► 


SetType 17 


—fr ^SET » ^OF^ —► SimpleType 18 


SimpleType lg 
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RecordType 2 o 


—o— 

{ RECORD )-*->■ FieldList 21 -^U ^ENd} —»► 


FieldList 21 



VariantFieldList 22 











r 


>1 


CaseLabelList 24 


i h 

FieldList 21 

J 




4 * 
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CaseLabelList 2 4 


o 


ConstExpr 2 7 ► ConstExpr 27 


j 


PointerType 2 5 


—►( POINTER~^-»( TO )-* Type 


36 


Co nstDecl aratio n 26 


Ident 


D-*© - *. 


ConstExpr 27 


.-KD- 


ConstExpr 27 



Relation 2 g 
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ConstTerni3Q 


r 

MulOperator 31 





i ^ 

ConstFactor 32 

V 




MulOperator 31 



ConstFactor32 



ConstSet 33 
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ConstElement3 4 



ConstExpr 2 i 

—■s 

<h 

ConstExpr 21 

— Y 




V 


J 


TypeDeclaration3 5 


Ident 


KEH Type 36 KD- 


Type 36 



VariableDeclaration 37 


Xr^nl 

Ident , -Kt 


GK Type 36 KD- 
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Designator 38 



SimpleExpression ^ 


Term 41 
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Factor 42 



Set 43 


o + 


-y* 

Qualldent 2 - 

* - 

Element 44 — 

Wd-* 



J V 


> 


Element^ 


Expression 39 


Expression 


39 
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Statement 45 



Assignment^ 


Designator 33 ——► 


Expression 39 


IfStatement 47 


Expression 39 —»^THEN^—► 


StatementSequence 14 




ELSIF ^ —► Expression 39 — ^THEN^ —► StatementSequence 14 

^(else> 


StatementSequence 14 


{Wh 
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CaseStatement 4 g 

—+ Q CASE ► Expression 39 —+ Q OF 


/ 



-4-^- 


s. > 

CaseLabelList 24 


StatementSequence 14 


f — i 

V 




_> 


/" 





_/ 


^-» ^ELSEJ —► StatementSequence 14 


<end)—► 


WhileStatement 49 


♦(WHILE )—► 

Expression 39 

—►( DO )-^ 








StatementSequence 14 

—►(END)—► 


RepeatStatement 50 

—»^REPEAT StatementSequence H UNTIL Expression 


39 


ForStatement 51 


—+ Q FOR » Ident ! ——* Expression 39 


o>* 

Expression 39 

—s 


ConstExpr 27 

\ 



-J 



_/ 



DO 


StatementSequence l4 


{end)-> 
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LoopStatement 52 


— LOOP » StatementSequence l4 
ExitStatement 5 3 


-* ( EXIT » 


WithStatement 54 


[wiTH }—> 

Designator 38 

—>( 0 °) v 


r 






StatementSequence 14 

-^end)-> 


ProcedureDeclaration 55 


ProcedureHeading 56 



Block 12 

-*^end}—► 

Ident ! 


ProcedureHeading 56 
—►( PROCEDURE Ident , 


Formalparameters 57 


rKD - * 


Formalparameters^ 


-o 



r 

w'— 

\ 


i k 

ParamSection 58 

y 






Quaiident 
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ParamSection 58 


VAR y 


o 


Ident 


dH FormalType 


59 


FormalType 59 


% 

-►( ARRAY )-*( OF )- 

4 * 

QualIdent -2 


V J 




ProcedureCall 60 


Designator 38 


G> 


G> 


I 


Expression 39 


< 2 > 


RetumStatement 61 


—RETURN y 


\ . 

Expression 39 


/ A 





V. 


J 



ProcedureType 62 

—^ PROCEDURE y 


FormalTypeList 63 
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FormalTypeListgj 


o 


HHH*(™L) 


FormalType 59 


<i> 


•dH Qualldent 


ModuleDeclaration 64 


H MODULE H Ident 


Priority 7 2 


KD—i 


Import 65 


I 


Export 66 


J 


r 





Block 12 

-^end}-*> 

Ident i 


—dH 


Import 65 


( FROM ) —*• Ident , IMPORT ) 


o 


Ident 


<H 


Export 66 


—►( EXPORT QUALIFIEP ^ 


O 


Ident 
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DefinitionModule 67 



Definition^ 


CONST y 


n 


ConstDeclaration 2 6 




TYPE 




n 


TypeDefinition 69 


n. 


VAR 




VariableDeclaration 37 


n. 


* ProcedureHeading 56 


TypeDefinition^^ 


Ident 


€M Type 36 | hrO 


ImplementationModu^Q 


IMPLEMENTATION ")—> ProgramModule „ 
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TypeTransfer 71 


Quaiident 


► Expression 39 —► 


Priority 7 2 


-<EK 


ConstExpr 2 i 
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C. Liste der Befehle des Motorola-68000-Prozessors 

Die Befehle sind in einem kompakten Format wie im folgenden Beispiel dargestellt: 


ADD ea,Dn / ADD Dn,ea 
B WL 

Dn An (An) (An)+ -(An) d(An) 
S:* * WL * * * 

D: * * * * 


Addiere 
S+D —> D 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

* * * * * * 

* * * 


In der ersten Zeile steht immer der Befehl in den erlaubten Syntax-Formen, gefolgt von 
einer kurzen Erklärung. 

Dn ist ein beliebiges Datenregister. 

An ist ein beliebiges Adreßregister. 

Rn ist ein beliebiges Adreß- oder Datenregister. 

S ist der Source-(Quell) Operand. 

D ist der Destination-(Ziel) Operand. 

#K ist eine Konstante 
d ist die Adreßdistanz 

In der zweiten Zeile stehen die erlaubten Operandengrößen (B, W, L). Darunter stehen die 
möglichen Adressierungsarten. Ein »*« heißt, daß alle vorgenannten Operandengrößen auch 
bei dieser Adressierung erlaubt sind. Ein oder zwei Buchstaben beschränken die Adres¬ 
sierungsart auf die durch die Buchstaben angedeuteten Operandengrößen. 

cc in zum Beispiel DBcc heißt »Condition Code«. Seine Bedeutung ist auf der letzten Seite 
dieses Anhangs aufgeführt. 


ABCD Dn,Dn / ABCD -(An),-(An) Addiere BCD 

B S+D+X —> D 


ADD ea,Dn / ADD Dn,ea 
B WL 


Addiere 
S+D —> D 
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Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

S:* WL 

* 

* * 

* 

* * * 

* * 

* 

D:* 

* 

* * 

* 

* * * 



ADDA ea,An 




Addiere Adresse 



WL 




S+D —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

S;* * 

* 

* * 

* 

* * * 

* * 

* 

Wortoperand wird wie bei EXT.L erweitert 




ADDI #K,ea 




Addiere Konstante 



B WL 




#K+D —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

D:* 

* 

* * 

* 

* * * 



ADDQ #K,ea 




Addiere Konstante Quick (#K <=8) 


B WL 




#K+D —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

D:* WL 

* 

* * 

* 

* * * 



ADDX Dn,Dn / ADDX -(An),-(An) 


Addiere mit X-Flag 



B WL 




S+D+X —> D 



AND ea,Dn / 

AND Dn,ea 


Logisch UND 



B WL 




S AND D —> D 



DN AN 

(AN) 

(AN)+ -(AN) D(AN) 

D(AN,RN) $.W $.L 

d(PC) d(PC,RN) # 

S:* 

* 

* * 

* 

* * * 

* * 

* 

D: 

* 

* * 

* 

* * * 




ANDI #K,ea 
B WL 


Logisch UND mit Konstante 
#K AND D —> D 
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Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

£);* * * * * * * * 


ANDI 

#K,CCR 

Unde zu CCR 


B 


#K AND CCR 

—> CCR 

ANDI 

#K,SR 

Unde zu SR 

! Privilegiert! 

W 


#K AND SR - 

-> SR 


ASL Dn,Dn / ASL #K,Dn / ASL ea 
B WL 


Arithmetisch links schieben 
D n Bits geschoben —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

0 wird nachgeschoben, herausgeschobenes Bit geht in das C- und X-Flag 


ASR Dn,Dn / ASR #K,Dn / ASR ea 
B WL 


Arithmetisch rechts schieben 
D n Bits geschoben —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

MS-Bit schiebt, bleibt aber erhalten. Herausgeschobenes Bit geht in das C- und X-Flag 


Bcc Label 

Verzweige wenn cc (PC-relativ) 

.B W 

siehe cc-Tabelle 

.S 

PC+d —> PC 


BCHG Dn,ea / BCHG #K,ea Bit n Testen und ändern 

B L Bit-Test —> Z-Flag 

Bit ändern 

Wenn Source Dn: n=0..31, sonst 0..7. Wenn Destination im RAM, wird immer 1 Byte 
gelesen und n=n mod 8. 

Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D:L B B B B B B B 
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BCLR Dn,ea / BCLR #K,ea 


Bit n Testen und Löschen 


B L 



Bit-Test —> Z-Flag 

Bit = 0 


Wenn Source Dn: n=0..31, sonst 0..7. Wenn Destination im RAM, wird immer 1 Byte 


gelesen und n= 

=n mod 8. 




Dn An 

(An) (Aji)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC.Rn) 

# 

D:L 

B B B 

B 

B B B 


BRA Label 



Verzweige zu Label (PC-relativ) 


.B W 
.S 



PC+d —> PC 


BSET Dn,ea / BSET #K,ea 


Bit n Testen und Setzen 


B L 



Bit-Test —> Z-Flag 

Bit = 1 


Wenn Source Dn: n=0..31, sonst 0..7. Wenn Destination im RAM, wird immer 1 Byte 


gelesen und n= 

=n mcxl 8. 




Dn An 

(An) (An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

D:L 

B B B 

B 

B B B 


BSR Label 



Call Sub bei Label (PC-relativ) 


.B W 
.S 



PC —> -(SP); PC+d —> PC 


BTST Dn,ea / BSET #K,ea 


Bit n Testen 


B L 



Bit-Test —> Z-Flag 


Wenn Source Dn: n=0..31, sonst 0..7. Wenn Destination im RAM, wird immer 1 Byte 


gelesen und n= 

=n mod 8. 




Dn An 

(An) (An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

D:L 

B B B 

B 

B B B B B 


CHK ea,Dn 



Register gegen Limits checken 
if Dn <0 or Dn >(ea) then trap 


W 





Dn An 

(An) (An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

S:W 

WWW 

W 

W W W W W 

W 
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CLR ea 




Lösche Operand 


B WL 




0—>D 


Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

D:* 

* 

* * 

* 

* * * 


CMP ea,Dn 




Vergleiche Operanden 


B WL 




Flags wie nach D minus S 


Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

S:* WL 

* 

* * 

* 

* , * * * * 

* 

CMPA ea,An 



Vergleiche Adressen 


W L 




Flags wie nach D minus S 


Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

S:* * 

* 

* * 

* 

* * * * * 

* 

Wort-Operand wird vorher auf Long erweitert 



CMPI #K,ea 




Vergleiche gegen Konstante 


B WL 




Flags wie nach D minus S 


Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

D:* 

* 

* * 

* 

* * * 


CMPM (An)+,(An)+ 



Vergleiche Speicherstellen 


B WL 




Flags wie nach D minus S 


DBcc Dn,Label 



Teste cc. Dekrementiere Dn. Branch 






if cc = false then Dn-Dn-1 
if Dn <> -1 then BRA Label 






eise »hier weiter« 


D1VS ea,Dn 




Dividiere Worte Signed 


W 




D/S —> D 


Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) 

# 

S:* 

* 

* * 

* 

4 = + ♦ ♦ + 

* 


Quotient im niederwertigen Wort, Rest im höherwertigen 
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DIVU ea,Dn Dividiere Worte Unsigned 

W D/S —> D 

Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

g.* * * * * * * * * * * 

Quotient im niederwertigen Wort, Rest im höherwertigen 


EOR Dn,ea 

B WL 

Logisch XOR 

S xor D —> D 

Dn An (An) 

D:* * 

(An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

* He * H« * He 

EORI #K,ea 

BL 

Logisch XOR mit Konstante 

S xor D —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

Dl* He * He * He He He 


EORI #K,CCR 

B 

XOR Konstante mit CCR 

S xor CCR —> CCR 

EORI #K,SR 

W 

XOR Konstante mit SR IPrivileg. ! 

S xor CCR —> CCR 

EXG Rn,Rn 

L 

Tausche Register 

Rn <—> Rn 

EXT Dn 

WL 

Dn vorzeichenrichtig erweitern 

ILLEGAL 

löst Illegal-Exception aus 

JMP ea 

absoluter Sprung (lang) 

D —> PC 
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Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

£)• * ****** 


JSR ea absoluter UP-Aufruf 

PC —> -(SP); D —> PC 

Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D : * ****** 


LEA ea,An 
L 


Lade effektive Adresse 
D —> An 


Dn 

D: 


An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

* * ***** 


LINK An,#d Lokalen Stack einrichten 

An —> -(SP); SP —> An; SP+d —>SP 
LINK und UNLK werden gebraucht, um eine »linked list« von lokalen Variablen für ver¬ 
schachtelte UP-Aufrufe anzulegen 


LSL Dn.Dn / LSL #K,Dn / LSL ea 
B WL 


Logisch links schieben 
D n Bits geschoben —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

0 wird nachgeschoben, herausgeschobenes Bit geht in das C- und X-Flag 


LSR Dn,Dn / LSR #K,Dn / LSR ea 
B WL 


Logisch rechts schieben 
D n Bits geschoben —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

0 wird nachgeschoben, herausgeschobenes Bit geht in das C- und X-Flag 


MOVE ea,ea 
B WL 


Kopiere Daten 
D—>S 
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Dn An (An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W 

$.L d(PC) d(PC.Rn) 

# 

S:* WL * 

* * 

* 

* * 

* * * 

* 

D: * * 

* * 

* 

* * 

* 


MOVE ea.CCR 



CCR laden 



w 



ea —> CCR 



Zwar ist das CCR nur 8 Bit breit, bei Bewegung eines Wortes in das CCR wird die obere 

Worthälfte jedoch ignoriert. 





Dn An (An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W 

$.L d(PC) d(PC,Rn) 

# 

S: * * 

* * 

* 

* * 

* * * 

* 

MOVE ea,SR 



SR laden 

! Privilegiert! 


w 



ea —> SR 



Dn An (An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W 

$.L d(PC) d(PC,Rn) 

# 

g.* * 

* * 

* 

* * 

* * * 

* 

MOVE SR,ea 



SR holen 

! Privilegiert! 


W 



SR —> ea 



Dn An (An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W 

$.L d(PC) d(PC,Rn) 

# 

D:* * 

* * 

* 

* * 

* 


MOVE USP, An MOVE An.USP 


USP holen und laden ! Privilegiert! 


L 



USP —> An 



MOVEA ea,An 



Kopiere Adresse 


WL 



ea —> An 



Dn An (An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W 

$.L d(PC) d(PC,Rn) 

# 

g : * * * 

* * 

* 

* * 

* * * 

* 


MOVEM RJListe.ea / MOVEM ea,R_Liste Register-Liste kopieren 
WL 

Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

j. * * * * * 

2 * * * * ***** 

1= Register —> Speicher z. B.: movem dl-d3/al-a4,-(a7) 

2= Speicher —> Register z. B.: movem (a7)+,dl-d3/al-a4 
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MOVEP Dn,d(An) / MOVEP d(An),Dn Daten von / zu Peripherie 

WL 

Daten werden byteweise übertragen 


MOVEQ #K,Dn 

L 



Übertrage »Quick« 
#K(8 Bit) —> Dn 



MULS ea,Dn 




Multipliziere Signed 



w 




S*D —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

S:* 

* 

* * 

* 

* * * 

* * 

* 

MULU ea,Dn 




Multipliziere Unsigned 


w 




S*D —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

S:* 

* 

* * 

* 

* * * 

* * 

* 

NBCD ea 




Negiere BCD-Zahl 



B 




0-D-X —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

D:* 

* 

* * 

* 

* * * 



NEG ea 




Negiere Operand 



B WL 




0-D —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

D:* 

* 

* * 

* 

* * * 



NEGX ea 




Negiere Operand mit X-Flag 


B WL 




O-D-X —> D 



Dn An 

(An) 

(An)+ -(An) 

d(An) 

d(An,Rn) $.W $.L 

d(PC) d(PC,Rn) 

# 

D:* 

* 

* * 

* 

* * * 



NOP 




No Operation 



tue nichts (dauert 4 Clock-Zyklen) 
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NOTea 

B WL 

Logisch Nicht 

-D —> D (Einer-Komplement) 

Dn An (An) (An)+ 
£).* * * 

-(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

* * * * * 

OR ea,Dn / OR Dn,ea 

B WL 

Logisch ODER 

S or D —> D 

DN AN (AN) (AN)+ 
§.* * * 

£)•* * * 

-(AN) D(AN) D(AN,RN) $.W $.L D(PC) D(PC,RN) # 

ORI #K,ea 

B WL 

Logisch ODER mit Konstante 
#K or D —> D 

Dn An (An) (An)+ 

D ; * * * 

-(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

=ic jjc Sf: jjc 

ORI #K,CCR 

B 

Ödere zu CCR 
#K or CCR —> CCR 

ORI #K,SR 

W 

Ödere zu SR ! Privilegiert! 

#K or SR —> SR 

PEA ea 

L 

Push effektive Adresse 

D —> -(SP) 

Dn An (An) (An)+ 
D: * 

-(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

* * * * * * 

RESET 

Rücksetzen ! Privilegiert! 

Reset-Leitung für 124 Clock-Zyklen auf 0 


ROL Dn,Dn / ROL #K,Dn / ROL ea 
B WL 


Rotiere links 
D n Bits rotiert —> D 
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Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

MS-Bit geht ins LS-Bit und ins Carry-Flag und schiebt links 


ROR Dn,Dn / ROR #K,Dn / ROR ea 
B WL 


Rotiere rechts 
D n Bits rotiert —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 


LS-Bit geht ins MS-Bit und ins Carry-Flag und schiebt rechts 


ROXL Dn,Dn / ROXL #K,Dn / ROXL ea Rotiere links mit X-Flag 
B W L D n Bits rotiert —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

X geht ins LS-Bit und schiebt links. MS-Bit geht in X und Carry 


ROXR Dn,Dn / RORL #K,Dn / RORL ea Rotiere rechts mit X-Flag 
B W L D n Bits rotiert —> D 


Dn An (An) (An)+ -(An) d(An) d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D: WWWW WWW 

X geht ins MS-Bit und schiebt rechts. LS-Bit geht in X und Carry 


RTE 


Return von Exception ! Privilegiert! 

(Sp)+ —> SR; (SP)+ —> PC 


RTR Return mit Flag 

(Sp)+ —> CCR; (SP)+ —> PC 


RTS Return 

(SP)+ —> PC 


SBCD Dn,Dn / ABCD -(An),-(An) Subtrahiere BCD 

B D-S-X —> D 
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Scc 


Setze Byte wenn cc true 




B 


ifcc 

=true 

$FF - 

-> Byte 






eise 


$00 - 

-> Byte 




Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W 

$.L 

d(PC) d(PC.Rn) 

# 

D:* 

* 

* 

* 

* 

* * 

* 



STOP #K 


Lade SR und Halt 

! Privilegiert 

t 




#K - 

—> SR; Halt bis Interrupt 




SUB ea,Dn / ADD Dn,ea 



Subtrahiere 




B WL 





D-S —> D 




Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W 

$.L 

d(PC) d(PC.Rn) 

# 

5 . * * 

WL 

* 

* 

* 

* * 

* 

* * 

* 

D: * 

* 

* 

* 

* 

* * 

* 



SUBA ea,An 





Subtrahiere Adresse 



WL 





D-S —> D 




Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W 

$.L 

d(PC) d(PC,Rn) 

# 

S:* * 

* 

* 

* 

* 

* * 

* 

* * 

* 

Wortoperand wird wie bei EXT.L erweitert 





SUBI #K,ea 





Subtrahiere Konstante 


B WL 





D-#K —> D 




Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W 

$.L 

d(PC) d(PC,Rn) 

# 

D:* 

* 

* 

* 

* 

* * 

* 



SUBQ #K,ea 





Subtrahiere Konstante Quick (#K <= 8 ) 


B WL 





D-#K —> D 




Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W 

$.L 

d(PC) d(PC,Rn) 

# 

D:* WL 

* 

* 

* 

* 

* * 

* 



SUBX Dn,Dn / ADDX -(An),-(An) 


Subtrahiere mit X-Flag 


B WL 





D-S-X —> D 













Anhang 


517 


SWAP Dn 





Tausche Worte in Dn 

w 





Bit 31..16 <—> Bit 15..0 

TAS ea 





Teste und setze Bit 7 im Byte 

B 





Bit 7 —> N/Z-Flag 

1 —> Bit 7 

Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC.Rn) # 

D:* 

* 

* 

* 

* 

* * * 

TRAP #n 





Trap-Exception 

PC —> -(SSP) 

SR — > -(SSP) 

Vektor n — > PC 

TRAPV 





Trap, wenn Overflow 

TST ea 





Teste Operand gegen Null 

B WL 





Ergebnis in N/Z-Flag 

Dn An 

(An) 

(An)+ 

-(An) 

d(An) 

d(An,Rn) $.W $.L d(PC) d(PC,Rn) # 

D:* 

* 

* 

* 

* 

* * * 

UNLK An 





Unlink 

An —> SP; (SP)+ —> An 
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Die Bedeutung der Condition Codes 



Kürzel 

Bedeutung 

Deutsch 


cc 

Carry Clear 

Carry = 0 


cs 

Carry Set 

Carry = 1 


EQ 

Equal 

Z=1 


GE 

Greater or Equal 

>= 

*** 

GT 

Greater Than 

> 


HI 

Higher 

> 

*** 

LE 

Less or Equal 

< 


LS 

Less or Same 

<= 

*** 

LT 

Less Than 

< 


MI 

Minus 

- 


NE 

Not Equal 

<> 


PL 

Plus 

+ 

*** 

VC 

oVerflow Clear 

o 

ii 

> 

*** 

VS 

oVerflow Set 

V=1 


T 

True 

l 


F 

False 

0 


*** Für vorzeichenbehaftete Zahlen 
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D. Erweiterte ASCII-Tabelle 




32 

40C 

i 

! 

33 

410 

i 

ii 

34 

420 

i 

n 

35 

430 



$ 

36 

44C 

i 

/. 

37 

450 


s 

38 

460 

i 

i 

35 

470 



( 

40 

50C 

i 

) 

41 

510 


» 

42 

520 

i 

+ 

43 

530 



ß 

44 

54C 


- 

45 

550 

i 

i 

46 

560 

i 

/ 

47 

570 



0 

48 

60C 

i 

1 

43 

610 

i 

2 

50 

620 

i 

3 

51 

630 



4 

52 

64C 

i 

5 

53 

650 

i 

6 

54 

660 

i 

7 

55 

670 



8 

56 

70C 

i 

3 

57 

710 

i 

; 

58 

720 

i 

f 

55 

730 



< 

60 

74C 


= 

61 

750 


> 

62 

760 


? 

63 

770 



e 

64 

100C 

i 

H 

65 

1010 

i 

B 

66 

1020 


C 

67 

1030 



D 

68 

104C 

i 

E 

63 

1050 

i 

F 

70 

1060 

i 

G 

71 

1070 



H 

72 

110C 

i 

I 

73 

nie 

i 

J 

74 

1120 

i 

K 

75 

1130 



L 

76 

114C 


M 

77 

1150 

i 

N 

78 

1160 

i 

0 

75 

1170 



P 

80 

120C 


Q 

81 

1210 

i 

R 

82 

1220 

i 

s 

83 

1230 



T 

84 

124C 


U 

85 

1250 

i 

y 

86 

1260 


14 

87 

1270 



X 

88 

130C 


Y 

83 

1310 

i 

z 

30 

1320 

i 

C 

51 

1330 



\ 

32 

134C 

i 

] 

33 

1350 

i 

A 

34 

1360 

i 


55 

1370 



\ 

36 

140C 


a 

37 

1410 

i 

b 

38 

1420 

i 

c 

55 

1430 



d 

100 

1440 

i 

e 

101 

1450 

i 

f 

102 

1460 

i 

9 

103 

1470 



h 

104 

1500 

i 

i 

105 

1510 

i 

j 

106 

1520 

i 

k 

107 

1530 



1 

108 

1540 


ft 

103 

1550 


n 

110 

1560 


o 

111 

1570 



P 

112 

1600 

i 

q 

113 

1610 


r 

114 

1620 

i 

s 

115 

1630 



t 

116 

1640 


u 

117 

1650 

i 

V 

118 

1660 


H 

115 

1670 



X 

120 

1700 


y 

121 

1710 


z 

122 

1720 


{ 

123 

1730 



1 

124 

1740 

i 

> 

125 

1750 

i 


126 

1760 

i 

A 

127 

1770 



C 

128 

2000 

i 

ü 

123 

2010 

i 

e 

130 

2020 

i 

ä 

131 

2030 



ä 

132 

2040 

i 

ä 

133 

2050 

i 

a 

134 

2060 

i 

c 

135 

2070 



e 

136 

2100 


e 

137 

2110 

i 

e 

138 

2120 


l 

135 

2130 



f 

140 

2140 

i 

l 

141 

2150 

i 

8 

142 

2160 

i 

8 

143 

2170 



t 

144 

2200 


ae 

145 

2210 

i 

ft 

146 

2220 

i 

6 

147 

2230 



ö 

148 

2240 


0 

143 

2250 


0 

150 

2260 


ü 

151 

2270 



y 

152 

2300 


o 

153 

2310 

i 

ü 

154 

2320 


0 

155 

2330 



£ 

156 

2340 

i 

Y 

157 

2350 

i 

0 

158 

2360 


f 

155 

2370 



ä 

160 

2400 

i 

l 

161 

2410 

i 

d 

162 

2420 


u 

163 

2430 



n 

164 

2440 


N 

165 

2450 

i 

a 

166 

2460 


0 

167 

2470 



l 

168 

2500 


r 

163 

2510 

i 

-i 

170 

2520 

i 


171 

2530 



\ 

172 

2540 


j 

173 

2550 

i 

< 

174 

2560 


» 

175 

2570 



ä 

176 

2600 

i 

Ö 

177 

2610 

i 

0 

178 

2620 

i 

0 

175 

2630 



(E 

180 

2640 

i 

(E 

181 

2650 

i 

fl 

182 

2660 

i 

fl 

183 

2670 



d 

184 

2700 

i 


185 

2710 

i 


186 

2720 


T 

187 

2730 



Sl 

188 

2740 

i 

0 

183 

2750 

i 

0 

130 

2760 

i 

IM 

151 

2770 



y 

132 

3000 

i 

I) 

133 

3010 

i 

X 

134 

3020 

i 

1 

155 

3030 



a 

136 

3040 


1 

137 

3050 

i 

n 

138 

3060 

i 

1 

155 

3070 



i 

200 

3100 

i 

n 

201 

3110 

i 

D 

202 

3120 

i 

** 

203 

3130 



3 

204 

3140 


7 

205 

3150 

i 

Q 

206 

3160 

i 

J 

207 

3170 



ö 

208 

3200 

i 

li 

203 

3210 


0 

210 

3220 

i 

s 

211 

3230 



P 

212 

3240 

i 

i 

213 

3250 

i 

El 

214 

3260 

i 

n 

215 

3270 



1 

216 

3300 

i 

1 

217 

3310 

i 

D 

218 

3320 

i 

3 

215 

3330 




220 

3340 

i 

§ 

221 

3350 

i 

A 

222 

3360 

i 

00 

223 

3370 



K 

224 

3400 


ß 

225 

3410 

i 

r 

226 

3420 


ir 

227 

3430 



I 

228 

3440 


<5 

223 

3450 

i 

M 

230 

3460 

i 

r 

231 

3470 



$ 

232 

3500 

i 

0 

233 

3510 


ß 

234 

3520 


5 

235 

3530 



t 

236 

3540 

i 


237 

3550 

i 

6 

238 

3560 

i 

n 

235 

3570 



s 

240 

3600 


+ 

241 

3610 


> 

242 

3620 


< 

243 

3630 



r 

244 

3640 


J 

245 

3650 


T 

246 

3660 

i 

s 

247 

3670 



0 

248 

3700 

i 

• 

243 

3710 

i 

• 

250 

3720 


iT 

251 

3730 



fl 

252 

3740 

i 

2 

253 

3750 

i 

3 

254 

3760 

i 


255 

3770 
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Stichwortverzeichnis 


A 

Abbruchkriterium 82 
Abbruchsbedingung 62 
ABS (x) 34 

Ackermann-Funktion 118 
Adelson-Velskii 259 
Adresse 128 
Adreßregister 186 
AES 187,312 
Fensterverwaltung 321 
Routine 313 
Alertboxen 310, 325 
ALLOCATE 144 
Analog-Wandler 388 
AND 30, 297 
Anfangswert 83 
Anweisungsfolge 83 
Anweisungsteil 30 
Apfelmännchen 172 
Application Environment Service 312 
Arithmetik, komplexe 172 
-, schnellere 57 
ARRAY 24, 30, 124 
ASCII-Code 177 
ASCII-Wert 70 
ASClI-Zeichen 70 
ASCII-Zeichensatz 35 
Assembler-Anweisung 290 
Assemblerprogramm 290 
Assemblerroutine 307 
Atari-Bildschirm 73 
Atari ST 301 
Atari-Uhr 167, 187 
Attribut-Bibliothek 320 
Aufzählungstypen 119, 120 
Ausdruck 27, 43 
Ausdrucks-Kompatibilität 158 
Ausgaberoutine 21 
Ausgleichsgerade 382 
AVL-Bäume 259 


B 

Basic 12 

-, Input Output System 311 
Basisadresse 129, 211 
Befehle, arithmetische 288 
-, logische 288 
BEGIN 21, 26, 30 
Begrenzer 39 
BEISPIEL1.M 20 
Benutzeroberfläche 310 
Berechnung 152 
Betriebssystem 129, 301 
-, Funktionen 307 
-, Routinen 13 
Betriebssystemaufrufe 313 
Bibliotheksmodul 25, 175 
Bildpunkt-Koordinaten 56 
Bildschirm 56, 311 
Bildschirmausdruck 335 
Bildschirmkoordinate 53 
Bildschirmspeicher 304 
Bildschirmzeile 304 
Binder 19 
BIOS 187,311 
Bitmanipulationen 296 
Bitmanipulationsbefehle 288 
BOOLEAN 33 
Boolesche Funktion 230 
BY 30 


C 

C-Compiler 318 
CAP (ch) 35, 70 
CARDINAL 21, 24 
CASE31 

CASE-Anweisung 87, 88, 393 
CASE-Strukturen 181 
CATE 144 
CHAR 22, 24, 33 
CHR (i) 35, 70 
Compiler 19, 20 
Compileroption 390 
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Stichwortverzeichnis 


CONST31 
Coroutine 193 
CP/M 310 
Cursortaste 177 


D 

Dateien 263 
Dateiverwaltung 179 
Datenkapseln 191 
Datenmodule 191 
Datenregister 286 
Datensatz 236, 269 
Datenstruktur 12, 149 
-, »Baum« 236 
-, »Feld« 124 
-, »Menge« 140 
-, »Schlange« 229 
-, »Stapel« 218 
-, »Zeiger« 142 
-, dynamische 13, 149 
Datentransportbefehle 288 
Datentyp BITSET 73 
BOOLEAN 66 
-, CARDINAL 45 
-, CHAR 70 
-, INTEGER 51 
-, LONGCARD 49 
-, LONGINT 51 
-, LONGREAL 57 
-, PROZEDUR 155 
-, REAL 57 
Datentypen 40 
-, abstrakte 191, 224 
-, vordefinierte 44 
DEALLOCATE 144, 149 
Debugger 35 
DEC (ch) 70 
DEC (x) 35 
DEC (x,n) 35 
DEFINITION 31 
Definitionsmodul 165, 199 
Deklarationsteil 30, 40, 91,92 
Desktop 19 
Dezimalzahl 87 
Dialogboxen 310, 394 


Differentialgleichung 371 
Differenzierung 411 
Digital-Wandler 388 
Direktzugriff 264 
Disk-Monitor 299 
Diskette 263 
Diskettenzugriff 19 
DIV31 
DO 26,31 
Drucker 112 
Druckerspooler 329 
Druckprogramm 328 


E 

Editor 19 

Eingabe-Bibliothek 320 
Eingabeprozeduren 185 
Eingaberoutine 21 
Einrückungen 199 
ELSE 31 
ELSIF31 
END 21, 22, 24,31 
Endlos-Schleife 197 
Endwert 83, 

Environment Service 312 
Epson FX-80 333 
Ereignis-Bibliothek 320 
Ereignisbehandlung 389 
ESC-Zeichen 73 
Escape-Bibliothek 320 
Escape-Sequenz 73 
EXBIOS 187 
EXCL (m,i) 35 
EXIT31 
EXPORT 31 
EXPORT-Liste 162 
Expression 27 
Extendet BIOS 311 


F 

Fakultätsberechnung 107 
FALSE 34 

Feld, zweidimensionales 127 
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Feldelemente 149 
Felder 13 
Feldgrenze 237 
Feldgröße 217 
Feldparameter 131 
Fenster-Bibliothek 321 
Fenstertechnik 13, 356 
Festplatte 19, 263 
Fibonacci 111 
FIFO-Prinzip 229 
File-Selector-Box 310, 327 
Files 42, 187 
FLOAT (i) 35 
FLOATD (i) 37 
FOR31 

FOR-Schleife 21, 31, 82 
Formular-Bibliothek 320 
Fortran 11 

FORWARD-Deklaration 93 
FROM 31 

Fuchs-Kaninchen-Problem 373 
Funktion, rekursive 106 
Funktionsgraph 417 
Funktionsmodul 191 
Funktionsprozedur 98, 155 
Funktionstaste 177 
Funktionsvariable 157 


G 

Ganzzahl-Arithmetik 56, 57 
GDP-Routinen 333 
GEM 14, 179,310 
Bibliothek 56 
-, Bildschirm 393 
-, Menütechnik 388 
Module 187 
-, Oberfläche 268 
Programm 394 
Routinen 310 
Umgebung 399 
GEMDOS 167, 187,311 
Geometrie, fraktale 344 
GetDate 167 

Grafics Environment Manager 310 
Grafik, rekursive 342 


Grafik-Bibliothek 320 
Grafik-Routinen 56 
Grafikausgabe 411 
Großbuchstaben 142 
Grundrechenart 172 


H 

Hänisch-Modula-2 16,42 
Hardware 19 
Hash-Verfahren 278 
Heap 144 
HIGH (a) 36 
Hilfsspeicher 207 


I 

IBM-Computer 311 
IBM-Zeichensatz 73 
IEEE-Double-Precision-Format 57 
IEEE-Single-Precision-Format 57 
IF 31 

IF-Anweisung 31, 32, 85 
IF...THEN...ELSE 24 
IMPLEMENTATION 31 
Implementationsmodul 165 
IMPORT 24,31 
-, Liste 162 
Importliste 20, 28, 29 
IN 31 

INC(ch) 70 

INC(x) 36 

INC(x,n) 36 

INCL(m,i) 36 

Indexbereich 130 

Index Search Access Method 268 

Indextyp 124 

Initialisierung 82 

InOut 186 

INSTALL.PRG 20 

Installationsprozedur 19 

INTEGER-Variable 51 

Integrationsverfahren 456 

Integrierer 411 

Intelligenz, künstliche 451 
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Stichwortverzeichnis 


IOCALL 193 
IOTRANSFER 193 
ISAM 268 
ISO 38 

Iterationstiefe 346 


J 

Joker-Datentyp 76 
Julia Gaston 349 
Julia-Menge 172, 349 
Juliamengenprogramm 14 


K 

Kardinalzahl 139 
Kepler 375 

Kl-Programmierung 14,410 
Kleinbuchstabe 70, 142 
Knoten 244 
Kommentare 40, 199 
Kommentarklammern 199 
Kompilierungsvorgang 218 
Konsistenzkontrolle 232 
Konstante 92 

Konstantendeklaration 31, 41, 58, 77 
Kontrollprozedur 320 
Kontrollstruktur 43, 79 
Konvertierung 187 
Koordinatenkreuz 173 
Kosinus-Funktion 53 
Kreisdiagramm 359 
Kreisgleichung 53 


L 

Laufvariable 84 
Laufzeit 50, 416 
Laufzeitsystem 44 
Lautstärke 313 
Leerzeichen 23 
Leonardo von Pisa 111 
LIFO-Prinzip 218 
Line-A-Grafik 187,310 
-, Routinen 313, 321, 333 


Linker 19 
Listen 193 
LONG (i) 37 
LONGCARD-Wert 177 
LONGREAL 33 
LOOP 31 

LOOP-Schleife 31,81 


M 

Megamax-Compiler 61 
Mandelbrotmenge 172, 344 
Mandelbrotprogramm 14 
Maschinencode 290 
Maschinensprache 297 
Massenspeicher 263 
externer 263 
MathLib 186 
Mauspfeil 323 
MAX(T) 36 
MaxCard 34 
Maxint 34 
MaxLCard 34 
MaxLInt 34 

Megamax-Modula 16, 52, 291 
Mengen 42 

Mengenkonstante 142 
Menü-Bibliothek 320 
MIDI-Schnittstelle 311 
MIN(T) 36 
Minlnt 34 
MinLInt 34 
MOD 31 

Modul Coroutines 193 
-, InOut 28 
LowLevel 294 
-, MatheLehrer 451 
-, Optimierer 443 
-, SYSTEM 187 
-, Terminal 28 
VDIOutputs 352 
Modula-2 12 
Modula-Compiler 40 
Modula-Shell 19 
MODULE 20, 24, 26,31 
Module, externe 165, 198 
-, lokale 162 
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Modulhierarchien 191 
Modulkonzept 11, 160 
Modulkopf 28 
Modulname 30 
MS-DOS 310 
MSM2 16, 291 


N 

Nachfrageprozeduren 320 
NEWPROCESS 193 
Newton 375 
NIL 34 
Pointer 301 
NOT 31 


O 

Objekt-Bibliothek 320 
Objektbaum 389 
ODD (i) 36 
OF 31 

Operationen, speicherbezogene 294 
Operator 25, 39, 74 
logischer 31 
Optimierer 411 
OR 31, 297 
ORD(ch) 70 
ORD(x) 36 
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Parameter-Prozeduren 94 
Parameterliste 40, 130, 155 
Parser 411 
Pascal 11, 12, 30, 39 
Periodendauer 314 
Pixel 304 

Platte, optische 263 
POINTER 31, 42, 143 
Portabilität 193 
PROCEDURE 31 
Programmblock 28, 30 
Programmiertechnik 12 
Programmsteuerbefehle 288 


Programmstruktur 40 
Prozedur 22, 91 
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Typen 42 
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Prozeduraufruf 91, 107 
Prozedurdeklaration 42 
Prozedurenkonzept 90 
Prozedurenbibliothek 12 
Prozedurkopf 165 
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Prozeß, paralleler 193 
Pull-down-Menü 142, 310 
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QUALIFIED 31, 163 
Quelltext 38, 400 
Quicksort 208 
-, optimierter 210 
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RAM-Disk 19 
Rauschgenerator 314 
Read 28, 177 
ReadCard 23 
ReadString 22 
REAL 33 
-, Zahlen 323,417 
ReallnOut 186 
Rechenzeit 352 
Rechnertypen 307 
RECORD 32 
Regression, lineare 382 
Rekursion 
Rekursionsstack 211 
Rekursionstiefe 117 
REPEAT 24, 32 
REPEAT-Schleife 32, 79 
Resource-Construction-Set 389, 396 
Resourcebehandlungs-Bibliothek 320 
RETURN 32 
Anweisung 99 
ROM 311 

RS232-Schnittstelle 311 



526 


Stichwortverzeichnis 


Rücksprungadresse 116 
Rückzeiger 237 
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Schrittweite 82, 84 
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Shell 19 
SHORT(Li) 38 
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Sinus-Funktion 53 
SIZE(x) 37 
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Standardmodule, externe 186 
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Stapel 144 
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Suchen 236 
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-, sequentielles 203 
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SYSTEM 187, 193 
Systemaufrufe 288 
Systemfonts 339 
Systemprogrammierung 11 
Systemvariable 301 
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Tastaturbehandlung 177 
TDI-Modula 16, 263, 327 
Teilbaum 244 
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Terminalsymbol 26, 26 
Testbefehle 288 
Testprozeduren 245, 260 
Text-Bildschirm 268 
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THEN 32 
Timer 311 
TO 32 

Tonerzeugung 314 
Tongenerator 313 
Tonhöhe 313 
Tortengrafik 359 
TOS 310 
-, Bildschirm 179 
Tramil Operating System 310 
TRANSFER 193 
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Trap 334 
TRUE 34 
TRUNC(x) 37 
TRUNCD(x) 37 
Turbo Pascal 75, 297 
Typdeklaration 31, 32, 42 
TYPE 32 
Typgleichheit 158 
Typtransfer 52, 76 


U 

Umwandlungsfunktion 175 
Unix 321 

Unterbereichstypen 42, 119, 122 
Unterprogramm 74 
UNTIL 22, 24, 32 
USER-Modul 301 


V 

VAR 32 

VAR-Parameter 101 
Variable 21, 92 

Variablen-Bezeichner 28, 44, 155 
Variablen-Deklaration 44, 119 
VDI 187,312,313 
Ausgabefunktionen 352 
Grafik 310, 362 
-, Grafikroutinen 352 
Verbünde 13 
-, Variante 42 
Vergleich 152 
Vergleichsbefehle 288 
Vergleichselemente 211 
Verknüpfungen, logische 297 
Verschlüsselungsverfahren 299 
Verzweigung 31 
Virtual Device Interface 312 
Voltera 371 
VT52-Terminal 73 
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Wertebereich 33 
Werteparameter 107 
Wertetabelle 417 
WHILE 27, 32 
WHILE-Schleife 26, 32, 80 
Wiederholungsanweisung 79, 82 
Wirth, Nikolaus 11 
WITH 32 

Wörter, reservierte 30 
WriteCard 23 
WriteLn 21 
WriteString 21 
Wurzel 244 


X 

XBIOS311 
XOR 297 
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Zahlen, gebrochene 57 
reelle 57 
Zählvariable 83 
Zeichenkette 21, 179 
Zeichenkettenvariable 22 
Zeichensatz 73 
Zeigerkonzept 145, 218 
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Atari ST 




A. Plenge 

Atari-ST-3-D-Grafik und 
Animation 

Daß es gar nicht so schwierig 
ist, auch eigene 3-D-Grafik 
zu programmieren, wissen 
die wenigsten. Mit diesem 
Buch verstehen Sie, ange¬ 
fangen bei den einfachsten 
Problemstellungen, wie Sie 
dreidimensionale Grafiken 
auf Ihrem Atari ST planen, 
programmieren und darstel- 
ien. Wieviel dabei in Ihrem 
Rechner steckt, wird Ihnen 
klar, wenn Sie die Bilder in 
diesem Buch betrachten. 

• Ein Buch für Atari-ST-User, 
fortgeschrittene Program¬ 
mierer und für Grafik- 
Einsteiger - mathematische 
Grundkenntnisse sowie Pro¬ 
grammierkenntnis in Basic 
oder C werden vorausge¬ 
setzt. 

1989, 391 Seiten 
ISBN 3-89090-676-1 

DM 69,- 

(sFr 63,50/öS 538,-) 


W. Besenthal/J. Muus 

Atari-ST- 

Programmierpraxis 
Omikron-Basic 3.0 

Hier finden Sie alle Informa¬ 
tionen zum Schreiben pro¬ 
fessioneller Omikron-Basic- 
Programme! Alle längeren 
Programmbeispiele finden 


Sie auf der beigefügten 
Diskette. 

• Für den erfahrenen Omi¬ 
kron-Programmierer 
1988, 355 Seiten, 
inkl. Diskette 
ISBN 3-89090-608-7 
DM 59,- 

(sFr 54,30/öS 460,-) 



B. Reimann 

Atari-ST-Hardware- 

Handbuch 

Dieses Buch lüftet die 
Geheimnisse des Atari ST. 
So kompliziert und undurch¬ 
sichtig Ihnen die Wege Ihrer 
Daten auch Vorkommen - 
jetzt erhalten Sie Klarheit. 

Sie erfahren alles über Moni- 
tore, Diskettenlaufwerke, 
Festplatten und Drucker. 
Und wenn Ihr ST einmal 
streikt, finden Sie ausführli¬ 
che Fehlerbeschreibungen 
mit Hinweisen zur Fehlerbe¬ 
seitigung. Alle Schnittstellen 
sind sehr ausführlich be¬ 
schrieben. Zahlreiche Schal¬ 
tungen, Zusätze sowie 
Erweiterungen erleichtern 
Ihnen den Ausbau des 
Atari ST. 

1989, 288 Seiten 
ISBN 3-89090-671-0 

DM 69,- 

(sFr 63,50/öS 538,-) 
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Atari ST Modula-2 
Programmierhandbuch 


Die Autoren: 

STEFAN DÜRHOLT studiert Informatik, Mathematik und Physik an der Universität Karlsruhe. Als freier 
Mitarbeiter für ein Wuppertaler Softwareunternehmen hat er an der Entwicklung komplexer Softwarepakete 
mitgearbeitet. 

JOCHEM SCHNUR ist als Studiendirektor für Mathematik, Physik und Informatik an einem Wuppertaler 
Gymnasium tätig. Er verfaßte bereits ein Lehrbuch über Pascal. 


Modula-2 ist eine Weiterentwick¬ 
lung der Sprache Pascal. Ihr 
herausragendes Merkmal ist die 
Unterstützung der schrittweisen 
strukturierten Programmierung in 
separaten Einheiten, den Modu¬ 
len, die getrennt übersetzt, geprüft 
und anschließend zu einem Pro¬ 
gramm zusammengefügt werden. 
Der Anwender kann auf diese 
Weise leicht eigene Programm¬ 
bibliotheken erstellen. Darüber 
hinaus enthält die Sprache 
maschinen- und systemnahe Ele¬ 
mente, was insbesondere dem 
Atari-Programmierer elegante 
Möglichkeiten zum Gebrauch der 
Betriebssystem- und GEM- 
Routinen bietet. 

Das vorliegende Buch berücksich¬ 
tigt sowohl den Leser, der sich in 
diese Sprache einarbeiten will und 
nur wenig Programmierkenntnisse 
besitzt, geht aber in starkem Maße 


auch auf den erfahrenen Program¬ 
mierer ein, der mit den Sprachen 
Basic, C oder Pascal bereits 
vertraut ist. Beginnend mit grund¬ 
legenden Programmiertechniken 
wird der Leser schnell an profes¬ 
sionelle Module für den betreffen¬ 
den Themenkreis herangeführt. 
Die einzelnen Sprachelemente 
werden dabei anhand vieler, 
interessanter Beispiele darge¬ 
stellt. So findet man unter ande¬ 
rem Module zur Mandelbrot¬ 
menge (Apfelmännchen), zu 
Simulationen aus Biologie und 
Physik und ein komplettes Funk¬ 
tionenplotprogramm, das Kon¬ 
zepte der künstlichen Intelligenz 
aufzeigt. Daneben werden in 
vielen Anwendungssituationen 
Atari-interne Sachverhalte erklärt. 
Die Beschreibungen sind durch 
zahlreiche Abbildungen illustriert 
und geben viele Anregungen zur 
eigenen Programmierung. 


Aus dem Inhalt: 

• Spracheinführung 

• Behandlung wichtiger Daten¬ 
strukturen 

• Benutzung des 68000-Assem- 
blers unter Modula-2 

• GEM-Programmierung unter 
Modula-2 

• Entwicklung eines komplexen 
Programmpaketes unter Modula-2 

und vieles mehr. 


Die Begleitdisketten: 


• Die zwei doppelseitigen Disket¬ 
ten enthalten in 150 Modulen 
alle Programmbeispiele, teil¬ 
weise auch in kompilierter Form. 


Hardware-Anforderungen: 


• Atari der ST-Serie 

• Schwarzweiß- oder Farbmonitor, 
doppelseitiges Laufwerk 


Software-Anforderungen: 


• Modula-2 Compiler, zum Bei¬ 
spiel Megamax Modula-2 
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